[PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[H.J. Lu]

On Tue, Feb 3, 2015 at 1:20 PM, Sriraman Tallam <tmsriram@google.com> wrote:
> On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote:
>>> This was the original patch to i386.c to let global accesses take
>>> advantage of copy relocations and avoid the GOT.
>>>
>>>
>>> @@ -13113,7 +13113,11 @@ legitimate_pic_address_disp_p (rtx disp)
>>>   return true;
>>>      }
>>>    else if (!SYMBOL_REF_FAR_ADDR_P (op0)
>>> -   && SYMBOL_REF_LOCAL_P (op0)
>>> +   && (SYMBOL_REF_LOCAL_P (op0)
>>> +       || (HAVE_LD_PIE_COPYRELOC
>>> +   && flag_pie
>>> +   && !SYMBOL_REF_WEAK (op0)
>>> +   && !SYMBOL_REF_FUNCTION_P (op0)))
>>>     && ix86_cmodel != CM_LARGE_PIC)
>>>
>>> I do not understand here why weak global data access must go through
>>> the GOT and not use copy relocations. Ultimately, there is only going
>>> to be one copy of the global either defined in the executable or the
>>> shared object right?
>>>
>>> Can we remove the check for SYMBOL_REF_WEAK?
>>
>> So, what will then happen if the weak undef symbol isn't defined anywhere?
>> In non-PIE binaries that is fine, the linker will store 0.
>> But in PIE binaries, the 0 would be biased by the PIE load bias and thus
>> wouldn't be NULL.
>
> Thanks for clarifying.
>
>> You can only optimize weak vars if there is some weak definition in the
>> current TU.
>
> Would this be fine then?  Replace !SYMBOL_REF_WEAK (op0) with
>
> !(SYMBOL_REF_WEAK (op0) && SYMBOL_REF_EXTERNAL_P (op0))
>

The full condition is:

                  && (SYMBOL_REF_LOCAL_P (op0)
                       || (HAVE_LD_PIE_COPYRELOC
                           && flag_pie
                           && !SYMBOL_REF_WEAK (op0)
                           && !SYMBOL_REF_FUNCTION_P (op0)))

If the weak op0 is defined in the current TU, shouldn't
SYMBOL_REF_LOCAL_P (op0)  be true for PIE?

-- 
H.J.