https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |segher at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd say the bug is that the various instructions that use ds_form_mem_operand
predicate don't use a corresponding constraint.
So, during combine:
(insn 8 7 9 2 (parallel [
(set (reg:CC 120)
(compare:CC (mem/c:SI (plus:DI (reg/f:DI 110 sfp)
(const_int -12 [0xfffffffffffffff4])) [1
MEM[(struct Ath__array1D *)&m + 40000B]._current+0 S4 A32])
(const_int 0 [0])))
(clobber (scratch:SI))
]) "pr105325.C":11:30 2295 {*lwa_cmpdi_cr0_SI_clobber_CC_none}
(nil))
is matched, as the offset is signed 16-bit that is a multiple of 4.
But as it uses "m" constraint and LRA only cares about constraints, not
predicates, it is reloaded as
(insn 8 7 9 2 (parallel [
(set (reg:CC 100 0 [120])
(compare:CC (mem/c:SI (plus:DI (reg/f:DI 1 1)
(const_int 40036 [0x9c64])) [1 MEM[(struct
Ath__array1D *)&m + 40000B]._current+0 S4 A32])
(const_int 0 [0])))
(clobber (reg:SI 9 9 [125]))
]) "pr105325.C":11:30 2295 {*lwa_cmpdi_cr0_SI_clobber_CC_none}
(nil))
where it no longer satisfies the predicate but does satisfy the constraint.
It is unclear if there is any matching constraint for ds_form_mem_operand,
maybe wY? But not really sure about it.
