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

[Chris Lattner]

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