This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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))

Thanks
Sri

>
>         Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]