[meta] cases where we mishandle functions with weak linkage

[llvmbot]

Bugzilla Link	2742
Resolution	LATER
Resolved on	Jul 11, 2011 10:23
Version	unspecified
OS	Linux
Blocks	#2770 #2050 #2783
Reporter	LLVM Bugzilla Contributor

Extended Description

All kinds of passes, eg: IP constant propagation,
Andersen's, GlobalsModRef, the inliner, and probably
many other IP passes, are all wrong for functions
with weak linkage. The reason is that such functions
have a definition, but the definition may be wrong -
it can be replaced with something completely different
at link time. Rather than fixing up all passes, here
is a suggestion for how to solve all problems in one
fell swoop:

(0) make it illegal for a function to have weak
linkage.
(1) when creating a function F which should have
weak linkage, instead output it with a different
name ("F2"), and create a weak alias F which
links to F2. Calls to the function will be calls
to F, the alias. The optimizers won't see the
body for F, since there is none, so won't make
mistakes.
(2) at codegen time, undo this transform: output
F2 with name F and with weak linkage.

[llvmbot]

assigned to @asl

[llvmbot]

Remarks:
(1) "F2" should of course have internal linkage.
The transform in codegen prepare would then be:
if A is a (weak or otherwise) alias to an internal
global G, and G has no other uses, then remove A,
rename G to A and give it the linkage of the alias.
(2) Probably the verifier should check that functions
do not have weak linkage, rather than using an
assertion in the linkage setting methods. That way
codegen prepare can easily create functions with
weak linkage. The fact that this results in invalid
bitcode doesn't matter (codegen prepare already
produces invalid bitcode!).
(3) Old bitcode containing functions with weak
linkage needs to be auto-upgraded.
(3) This trick is presumably needed for other linkage
types: all those which make a function definition
unreliable.
(4) The same problem may occur for global variables
with initial values (I'm especially thinking of
constants). What do you want to bet that if C is
a global constant with weak linkage, then the constant
folder replaces loads from the constant with whatever
value is specified by the initializer? This is wrong
because the initial value may be replaced at link-time.
(I'm assuming that weak linkage is allowed for global
constants...). Anyway, this suggests that the trick
suggested in this PR should be applied more generally
than just to functions.

[lattner]

We don't need a metabug to track one other bug.

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#3277