https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80239
Thomas Preud'homme <thopre01 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|ra |
Component|target |rtl-optimization
Target Milestone|7.0 |---
--- Comment #1 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
Below is my analysis of the issue. I have a patch for that as well but
unfortunately it only works when applied at r235184 and same goes for reverting
r235184.
After changing:
(insn 608 40 41 2 (set (reg/f:SI 223)
(reg/f:SI 419)) dhry_1.c:101 794 {*thumb2_movsi_insn}
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 102 sfp)
(const_int -64 [0xffffffffffffffc0]))
(nil)))
into:
(insn 608 40 41 2 (set (reg/f:SI 223)
(plus:SI (reg/f:SI 102 sfp)
(const_int 16 [0x10]))) dhry_1.c:101 794 {*thumb2_movsi_insn}
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 102 sfp)
(const_int -64 [0xffffffffffffffc0]))
(nil)))
in curr_insn_transform (), process_alt_operands () choose the alternative with
the memory constraint (alternative 5) which leads the second operand to be of
class NO_REGS. It later reloads with:
(insn 638 0 0 (set (reg:SI 431)
(plus:SI (reg/f:SI 102 sfp)
(const_int 16 [0x10]))) 4 {*arm_addsi3}
(nil))
(insn 608 40 41 2 (set (reg/f:SI 223)
(plus:SI (reg/f:SI 102 sfp)
(const_int 16 [0x10]))) dhry_1.c:101 794 {*thumb2_movsi_insn}
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 102 sfp)
(const_int -64 [0xffffffffffffffc0]))
(nil)))
Then when analyzing insn 638, process_alt_operands decides that reg 431 needs
to be reloaded because its class (NO_REGS, inherited from the analysis of insn
638) does not intersect with ALL_REGS according to in_class_p ().
I believe the problem is that the equivalence stays with NO_REGS as register
class instead of being given that of a register (since it's going to be
reloaded into a register). My patch follows that path and as said above works
just after r235184 but the performance remains worse on recent trunk.
When looking at code generated by recent trunk, the issue mentionned in the
original post is not there which suggest that something else is at play.
