[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