This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][AArch64] Improve aarch64_legitimate_constant_p
- From: Richard Sandiford <richard dot sandiford at linaro dot org>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, James Greenhalgh <James dot Greenhalgh at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Mon, 06 Nov 2017 14:44:04 +0000
- Subject: Re: [PATCH][AArch64] Improve aarch64_legitimate_constant_p
- Authentication-results: sourceware.org; auth=none
- References: <AM5PR0802MB2610272348FB1C5DADA9665C83AA0@AM5PR0802MB2610.eurprd08.prod.outlook.com> <20171026153853.GC25439@arm.com> <DB6PR0801MB2053860EE7894E7B973F1AB1835E0@DB6PR0801MB2053.eurprd08.prod.outlook.com> <87vaiqkl1j.fsf@linux-m68k.org> <87efpby92p.fsf@linaro.org> <HE1PR0801MB2058398C14D58CA2D815BEFB83500@HE1PR0801MB2058.eurprd08.prod.outlook.com>
Wilco Dijkstra <Wilco.Dijkstra@arm.com> writes:
> Richard Sandiford wrote:
>>
>> Yeah, I'd hit this too. I think it's a latent bug that just
>> happened to be exposed by Wilco's patch: although the *movti_aarch64
>> predicate disallows const_wide_int, the constraints allow it via "n",
>> which means that the RA can rematerialise a const_wide_int that would
>> otherwise be spilled or forced to memory.
>
> Yes I explicitly disallowed const-wide-int because otherwise it failed in
> Fortran code. Clearly there were more corner cases...
>
>> Maybe the best fix would be just to go ahead and add support for
>> const_wide_int, as with the patch below.
>
> But then it always uses a MOV/MOVK expansion, no matter how complex.
> That's inefficient since it would take at most 8 instructions. It's best to load
> complex immediates from the literal pool, so we need a cutoff (eg. sum of
> aarch64_internal_mov_immediate of both halves <= 4), and use a literal load
> otherwise, just like we do for floating point constants.
>
> Note those tests are there to test literal pool accesses work as expected,
> so we need to change those to ensure they continue to test that.
OK. Would you mind having a look at that? I'm a bit swamped with SVE
stuff ATM :-)
Thanks,
Ricard