On 6 November 2017 at 15:44, Richard Sandiford <richard.sandif...@linaro.org> wrote: > Wilco Dijkstra <wilco.dijks...@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 :-) >
Hi, I've filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82964 to keep track of this. Christophe > Thanks, > Ricard
