https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
Richard Sandiford <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #17 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #16)
> (In reply to Richard Sandiford from comment #15)
> > > Yes, I considered adding this handling of (zero_extend Rx) to LRA. I'm
> > > confident
> > > it would fix this instance of the problem, if done correctly (it
> > > essentially
> > > already has code to deal with shortening subregs, which is somewhat
> > > similar
> > > in structure).
> > It should already be present, via the decompose_*_address mechanism.
>
> As get_index_term doesn't accept any _EXTEND as index outer code I don't see
> how (currently). It basically gets into the tie-breaker of leaving the
> operands
> after the loop in decompose_normal_address for baseness() to decide which of
> course gets it "wrong" on m68k (see my comment #5 where I checked :) ) ...
>
> > FWIW, aarch64 also supports (mem (plus (zero_extend R1) R2)) and works with
> > LRA, so I don't think there's a fundamental limitation.
>
> ... but obviously gets it right by luck on aarch64.
Hmm, ok. I think that's probably my bug then, so... taking.
> > > invalid, do something". Alternatively (and better) it needs to have a way
> > > to say "this
> > > address, while structurally valid, will need these regsets in those reg
> > > operands", generally (i.e. it should be possible to have targets with
> > > e.g. 4
> > > register operands, or such).
> > >
> > > If that's not possible then the design of the LRA-target interface is not
> > > yet complete IMHO.
> > Yeah, the current approach is the latter one (which I agree is better).
> > legitimate_address_p answers the question “is this address structurally
> > valid?” while BASE_REG_CLASS and INDEX_REG_CLASS specify the regsets that
> > should be used to reload registers in structurally valid addresses.
>
> Well, that then rules out targets that allow three registers in addresses.
> Or ones that have more complicated validity rules than "op1 here, op2 there".
> E.g. "when op1 is an even-numbered register, then op2 needs to be
> odd-numbered,
> and vice versa". Contrived, sure, but ISA might want to save a bit here or
> there in encoding.
>
> > Like you say, in practice it has to be done by using regsets, since the RA
> > needs to know “what do I need to do to make this valid?”. It shouldn't have
> > to use trial and error (trying particular hard registers to see if they're
> > valid).
>
> Agreed. I just think that BASE/INDEX_REG_CLASS as the only way of
> communicating that from the target to LRA is quite constraining. It means
> (like
> here) to always having to adjust LRA whenever a new target with other forms
> comes along. Basically: when the target has to look at the structure of
> an address to check validity (reasonably so), then it irks me that also
> LRA needs to get at the inner structure of those addresses for correctness.
> The latter part, the correctness, is what triggers me. If it's necessary for
> optimality: sure. But if LRA needs to be extended for correctness, then, ...
> meh.
But this is how it's always worked. The corresponding reload code is in
find_reloads_address_1, which similarly tries to tear apart an address, work
out whether something is a base or an index, and use that to calculate the
appropriate register class. ISTM this PR is just about an inconsistency
between the base/index identification in LRA vs reload.
The reg_renumber indirection performed by GO_IF_LEGITIMATE_ADDRESS for reload
only handled the initial register allocation. It didn't help for pseudos that
were spilled, or were allocated to the wrong class. The
BASE_REG_CLASS/INDEX_REG_CLASS mechanism was always required to work for
correctness, not just optimisation.
