linker should handle parameter attributes better

[llvmbot]

Bugzilla Link	2205
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@asl

Extended Description

Case 1: two declarations. Consider module a:

declare void @​f() nounwind

and module b:

declare void @​f()

If you do
llvm-link a.bc b.bc
then @​f is nounwind, while with
llvm-link b.bc a.bc
it is not nounwind. It would be safer to
have it not nounwind in both cases. More
generally, attributes should probably be
"and"'d together when the linker joins two
declarations.

Case 2: declaration and definition. Consider module a:

declare void @​f() nounwind

and module b:

define void @​f() {
ret void
}

Once again whether @​f is nounwind in the linked
module depends on the order. What should happen
is that the attributes from the definition should
win.

[lattner]

I'm not sure that all attributes can be treated uniformly that way. The merging probably has to be specific to the particular attribute. For example, clearing "zext" just because one translation unit is missing it is probably not ideal.

[llvmbot]

Anton plans to take care of this PR.
Devang points out that this needs to also work with system linkers doing
LTO like on darwin.

As for zext, it is safer to drop zext than to wrongly keep it. Consider
the return value: zext means that the function zero-extends the return
value before putting it in the return register.

Case 1: function zero-extends the value, but the function was not marked
zext. This is suboptimal but safe.
Case 2: function doesn't zero-extend the value, but the function was marked
zext. This will give wrong code!

So it seems to me that if you have two declarations, one with zext and
the other without, the safe (but perhaps suboptimal) thing to do is to
drop the zext.