PING: [PATCH] PR target/67215: -fno-plt needs improvements for x86

Jeff Law law@redhat.com
Tue Oct 27 21:02:00 GMT 2015


On 10/27/2015 09:42 AM, Ramana Radhakrishnan wrote:
>
>
> On 27/10/15 14:50, H.J. Lu wrote:
>> On Tue, Oct 27, 2015 at 7:34 AM, Ramana Radhakrishnan
>> <ramana.radhakrishnan@foss.arm.com> wrote:
>>>
>>>>
>>>> OK, then it's fairly x86-64 specific optimization, because we can't do "call *mem" in
>>>> aarch64 and some other targets.
>>>
>>> It is a fairly x86_64 specific optimization and doesn't apply to AArch64.
>>>
>>> The question really is what impact does removing the generic code handling have on aarch64 - is it a no-op or not for the existing -fno-plt implementation in the AArch64 backend ? The only case that is of interest is the bit below in calls.c and it looks like that may well be redundant with the logic in the backend already, but I have not done the full analysis to convince myself that the code in the backend is sufficient.
>>>
>>> -  && (!flag_plt
>>> -              || lookup_attribute ("noplt", DECL_ATTRIBUTES (fndecl_or_type)))
>>> -          && !targetm.binds_local_p (fndecl_or_type))
>>>
>>
>> -fno-plt is a backend specific optimization and should be handled
>> in backend.
>>
>
> HJ, Thanks for committing the change even when we were discussing the change - As I suspected the handling in the backend isn't sufficient, the call expanders need to handle this case in the AArch64 backend. Minimally tested -
>
> Ok if no regressions on aarch64-none-elf?
>
> regards
> Ramana
>
> * config/aarch64/aarch64.md (call, call_value): Handle noplt.
FWIW -ENOPATCH.

jeff



More information about the Gcc-patches mailing list