On 27/10/15 14:50, H.J. Lu wrote: > On Tue, Oct 27, 2015 at 7:34 AM, Ramana Radhakrishnan > <ramana.radhakrish...@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.