From 56cc9904803154c0779c78d47595f232e73c45af Mon Sep 17 00:00:00 2001 From: "Duncan P. N. Exon Smith" Date: Mon, 10 Mar 2014 23:42:28 +0000 Subject: 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. llvm-svn: 203513 --- llvm/lib/IR/Module.cpp | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'llvm/lib/IR/Module.cpp') diff --git a/llvm/lib/IR/Module.cpp b/llvm/lib/IR/Module.cpp index c8c07f2..1accd47 100644 --- a/llvm/lib/IR/Module.cpp +++ b/llvm/lib/IR/Module.cpp @@ -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)) -- cgit v1.1