https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64152
Renlin Li <renlin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |renlin at gcc dot gnu.org
--- Comment #3 from Renlin Li <renlin at gcc dot gnu.org> ---
As -mno-lra option is already deprecated since GCC 5 for arm/aarch64 backend.
This ICE doesn't manifest since then.
I came across an insn canonicalization problem which I think is similar to this
one, so I spent some time understanding what's going on in both cases. For the
record, below is what I found.
To reload the following insn,
(set (reg:DI 5 x5)
(plus:DI (reg/f:DI 31 sp)
(mem/u/c:DI (symbol_ref/u:DI ("*.LC201") [flags 0x2]) [0 S8
A64])))
two insns are generated by reload:
(set (reg:DI 5 x5)
(mem/u/c:DI (symbol_ref/u:DI ("*.LC201"))))
(set (reg:DI 5 x5)
(plus:DI (reg:DI 5 x5)
(reg/f:DI 31 sp))) {*adddi3_aarch64}
The second insn here is not an strict rtx, because the rtx pattern defined in
the backend doesn't allow the third operand to be SP register.
However, at this stage, the rtx pattern is required to be strict.
So this reload is rejected, forcing the reload pass to try other possibilities,
This eventually leads the the ICEs observed here.
I have checked that there is no insn canonicalization rule for this scenario.
Either the target should provided more relaxed add pattern or the reload pass
can
try to swap the source operands for this commutative operator.
