[PATCH] D19995: Optimize access to global variable references in PIE mode when linker supports copy relocations for PIE

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Mon May 9 15:41:16 PDT 2016


On 6 May 2016 at 13:37, Sriraman Tallam <tmsriram at google.com> wrote:
> tmsriram added a comment.
>
> In http://reviews.llvm.org/D19995#423481, @rafael wrote:
>
>> Sorry for the long reply, but I think it is critical we get this right.
>>
>> When a variable/function is defined in a shared library, either the library or the main program has to use a got. The other one can then use direct accesses.
>
>
> This seems partially correct as it does not addess this case. Let's say the shared library and the executable define the global variable but initialize it differently.  Then, if the shared library does not use the GOT it is not possible to suddenly create a copy relocation in the shared library (that is already built first and is also used by other executables) and you are now accessing a global variable with the incorrect initialization.  The global definition in the executable must take precedence and that is not happening here.

That is what I mean. At least one of them has to use a got. The other
one can have a direct access.


>> So the first question is: In your testcase/benchmark, is preemption required or is the variable/function more frequently accessed from the main binary than from the library that defines it? If not, you would probably get even better performance by disallowing preemption and have the library access its own symbols directly and main binary uses a got.
>
>
> For us atleast, we have the case that most of the globals end up in the executable and we do not want to conservatively use the GOT  because it was declared external in the modules accessing it.  In non-PIE mode, which has the identical problem, copy relocations are used.  Extend that to PIE mode.

OK, so you could get the desired performance by just disabling
preemption. Have you tried building with -fvisibility=protected?

>> Right now the llvm support for preemption is also really bad. We will pretend the symbol cannot be preempted and then at the last minute use a got.
>
>
> For global variables atleast, with ELF and X86, llvm support seems identical to GCC support regarding symbol preemption.

We probably just don't have as many optimizations for variables. The
easiest to notice is that we inline preemptible functions.

>
>> - -fPIC. Symbols can be preemepted, so use the preemptable linkage.
>
>> - No option or -fPIE: Symbols cannot be preempted:
>
>
> Maybe you covered this case else where, but we are really interested in extern symbol access with -fPIE.  Whether it is really external or not at link time is the right question.  It is hard to answer that at compile time and too conservative to commit to GOT access.

Note that in the above case "-fPIE" is in the same bullet and "no
option", so yes, it is covered and is assuming no preemption and that
symbols are locall (copy reloc will be used if the guess is wrong).


More information about the llvm-commits mailing list