[llvm-commits] patch: teach deadargelim to work on externally visible functions!
Chris Lattner
clattner at apple.com
Fri Jan 8 17:48:45 PST 2010
On Jan 5, 2010, at 2:58 AM, Török Edwin wrote:
>>> then why not do further optimizations based on this assumption, and
>>> really call the function we see
>>> (instead of going through the .plt and calling whatever that
>>> resolves to
>>> at runtime).
>>>
>>
>> Can you elaborate?
>>
>
> Currently an externally visible function is called like this (with
> -fPIC), even when we know
> the function is in the current module:
> callq foo at PLT
>
> Which does allow for an override at runtime (see example at bottom),
> but
> that is not what the optimizer assumed.
Does GCC do this? This seems "bad". Neither gcc or llvm does the
equivalent on darwin.
> My suggestion is:
> - why go through all the trouble of calling it via PLT, and allowing
> runtime override, when what we really want
> is call the function we see? We could call it directly, i.e.:
> callq foo
This makes sense to me, this is what I thought we did already. :)
> - from an ELF symbol visibility point of view this would mean the
> symbols should get protected visibility, instead of default visibility
How does this affect visibility?
> - 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.
-Chris
More information about the llvm-commits
mailing list