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 :-) Thanks, Ricard
