https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #14 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Richard Sandiford from comment #13)
> (In reply to Michael Matz from comment #12)
> > That's why I struggle a bit, I lack the bigger picture, how LRA is
> > envisioned to deal with these situations given how targets are supposed (and
> > still documented)
> > to use the strict/nonstrict distinction of testing for legal operands.
> The generic address decomposition logic should realise that, in:
>
> (plus (zero_extend R1) R2)
>
> R2 must be the base and R1 must be the index. Therefore, R2 must be
> constrained to BASE_REG_CLASS (or its variants) and R1 must be constrained
> to INDEX_REG_CLASS (or its variants).
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).
But then I asked myself "what if another target has still
different representations of address?": Should LRA be continuously extended
to deal with these and those representations? Sure, for optimality that might
be necessary. But in the grand scheme of things, the target should have the
opportunity, without any changes to LRA code, to be made completely working
with whatever representations it's using internally. It needs to have a way
to say "this address, if written with the assigned hardregs, will be 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.
> If that isn't happening then I agree it's an LRA bug.
It's not happening simply because LRA doesn't handle {ZERO,SIGN}_EXTEND
specially at all, it's opaque. But the question is: should it have to? I'm
not
sure I agree with you, because in my mind it points to a deficiency in the
target interface.
> (FWIW, I think it's correct that LRA never passes strict_p==true.
> The strict_p distinction should go away once reload does.)
But how could it? The various target hooks are called from LRA when the
pseudos are _not_ yet replaced with their MEMs or their hardregs. How would
the target know to do this substitution internally for correctness checking?
How would it know that one pseudo is equivalent to a MEM, and another to a
hardreg? Looking at lra_in_progress as some targets are currently doing (and
my hack does)? That doesn't sound like a good design, it's simply a hidden
parameter for the target hook in a global variable.
So, how else? Substituting before the hooks are asked is just busy work,
not asking the target at all means continuously adding stuff to LRA whenever a
target wants something more.
Hmm.
