https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
Richard Sandiford <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #13 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #12)
> _Here_ we have a case where the target isn't even in the position to reject
> an invalid address (or one that definitely _will_ become invalid), because
> IRA/LRA don't make use of the strict predicates, and even if it were I don't
> see any code dealing with the fall-out of the target saying that
> '(plus (zero_extend(a0)) (d0))' would be invalid but
> '(plus (zero_extend(d0)) (a0))' would be valid.
> (my hack rectifies this a bit in forcing LRA to just reload the whole
> invalid address to another reg, but it doesn't fix all failures of this mode
> in the testsuite)
>
> 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). If that isn't happening then I agree
it's an LRA bug.
(FWIW, I think it's correct that LRA never passes strict_p==true.
The strict_p distinction should go away once reload does.)
