On Mon, Nov 06, 2017 at 01:50:07PM +0000, Wilco Dijkstra wrote:
> 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.
Can we apply Richard's patch and then perhaps incrementally improve stuff,
like selecting a subset of CONST_WIDE_INTs we want to accept for movti/movtf
and corresponding constraint that would be used instead of the "n" in
*movti_aarch64?
I mean, the trunk shouldn't remain so broken for months after a correct
patch has been posted.
For the new predicate/constraint, you can e.g. have a look at i386
x86_64_hilo_int_operand predicate which does a similar thing and is used for
similar stuff, namely a constant that is meant to be split and each half
needs to satisfy something. If it is a purely performance/-Os thing, you
could as well count the number of instructions you'll need to construct it
or similar. E.g. in the pr83726.C case, even when it is a CONST_WIDE_INT,
it is a rather cheap one, one half is 70, the other half 0.
Jakub
