mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2025-07-16 11:24:39 +00:00
Module: Don't rename in getOrInsertFunction()
During LTO, user-supplied definitions of C library functions often exist. -instcombine uses Module::getOrInsertFunction() to get a handle on library functions (e.g., @puts, when optimizing @printf). Previously, Module::getOrInsertFunction() would rename any matching functions with local linkage, and create a new declaration. In LTO, this is the opposite of desired behaviour, as it skips by the user-supplied version of the library function and creates a new undefined reference which the linker often cannot resolve. After some discussing with Rafael on the list, it looks like it's undesired behaviour. If a consumer actually *needs* this behaviour, we should add new API with a more explicit name. I added two testcases: one specifically for the -instcombine behaviour and one for the LTO flow. <rdar://problem/16165191> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203513 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
@@ -104,16 +104,6 @@ Constant *Module::getOrInsertFunction(StringRef Name,
|
||||
return New; // Return the new prototype.
|
||||
}
|
||||
|
||||
// Okay, the function exists. Does it have externally visible linkage?
|
||||
if (F->hasLocalLinkage()) {
|
||||
// Clear the function's name.
|
||||
F->setName("");
|
||||
// Retry, now there won't be a conflict.
|
||||
Constant *NewF = getOrInsertFunction(Name, Ty);
|
||||
F->setName(Name);
|
||||
return NewF;
|
||||
}
|
||||
|
||||
// If the function exists but has the wrong type, return a bitcast to the
|
||||
// right type.
|
||||
if (F->getType() != PointerType::getUnqual(Ty))
|
||||
|
Reference in New Issue
Block a user