[patch] Don't rename in Module::getOrInsertFunction.

[Rafael Espíndola]

> I actually started with this (see [1]), but I imagined some use cases where
> the current behaviour might be correct.  For example, what if someone gives
> a static function the same name as a libc function that they aren’t using
> (and maybe don’t even know about), and then LLVM inserts a use of the libc
> function.  Should this use call their potentially unrelated function, or
> the libc function?

Right now we are inconsistent in that regard. For something like a
printf -> puts transformation that happens at the IR level, llvm will
call the libc function. Run the attached testcase over instcombine to
see it in action.

On the other hand, for some expansion that happens in codegen, we will
call the user function. See the attached test1.c for example.

The patch changing Module::getOrInsertFunction makes the IR level case
behave like the codegen level case.

CCing Richard to see if there is a right answer for this or if it is
just undefined.

Whatever the correct/desirable behavior is, it should be implemented
explicitly, not by depending on a particular behavior of
Module::getOrInsertFunction deep down in llvm.

> Also possible to hit this on LTO with static C functions.  That is,
>
> static int foo()
>
> is this in the IR when its a C file.  Linking 2 of these IR files together
> needs to ensure we don’t clash on names.
>
> define internal i32 @foo() nounwind ssp uwtable

This is explicitly handled by the linker already (as noted by Duncan).

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test3.ll
Type: application/octet-stream
Size: 1420 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140310/b6142c18/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1.c
Type: text/x-csrc
Size: 207 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140310/b6142c18/attachment.c>