[llvm-commits] patch: teach deadargelim to work on externally visible functions!

Dan Gohman gohman at apple.com
Fri Jan 8 18:34:41 PST 2010


On Jan 8, 2010, at 5:48 PM, Chris Lattner wrote:

> On Jan 5, 2010, at 2:58 AM, Török Edwin wrote:
>>  - then we would get consistent behavior from optimized and
>> non-optimized code
>>  - you get same behavior regardless which file you place your  
>> function
>> into, it will always get called directly, instead of indirectly via  
>> the PLT
>> 
>> Here is an example where the link order of shared libs causes a
>> different function to be called:
> ...
> 
> This example has undefined behavior, so it doesn't matter what we  
> produce.  We should just always generate the faster code.  This sounds  
> like a pretty serious performance bug on ELF systems.


It may be as simple as this:

--- lib/Target/X86/X86ISelLowering.cpp	(revision 93032)
+++ lib/Target/X86/X86ISelLowering.cpp	(working copy)
@@ -1984,6 +1984,7 @@
       // we don't need to use the PLT - we can directly call it.
       if (Subtarget->isTargetELF() &&
           getTargetMachine().getRelocationModel() == Reloc::PIC_ &&
+          (GV->isDeclaration() || GV->isWeakForLinker()) &&
           GV->hasDefaultVisibility() && !GV->hasLocalLinkage()) {
         OpFlags = X86II::MO_PLT;
       } else if (Subtarget->isPICStyleStubAny() &&

At least, this does the right thing on the most trivial testcase,
and it's the same logic that the Darwin code uses, 5 lines later. Can
someone familiar with this check this?

Dan





More information about the llvm-commits mailing list