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

Pete Cooper peter_cooper at apple.com
Mon Mar 10 12:01:02 PDT 2014

On Mar 10, 2014, at 11:52 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:

> On Mar 10, 2014, at 11:35 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> Duncan recently reminded me that Module::getOrInsertFunction can
>> rename globals to make the new one fit. That is fairly surprising,
>> given the name of the function and what a central part of llvm it is.
>> Going over git log it looks like this was done to help with the
>> transition out of type planes. I have already done a simple "ninja
>> check-all" and both clang's and llvm's tests are clear. I will also
>> try a bootstrap and running the llvm testsuite.
>> Is the attached patch OK if all of the above works?
>> Cheers,
>> Rafael
>> <t.patch>
> 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?
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

> [1]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140224/206842.html
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140310/c938d329/attachment.html>

More information about the llvm-commits mailing list