https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |aarch64-linux
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-07-06
CC| |segher at gcc dot gnu.org,
| |sje at gcc dot gnu.org,
| |vmakarov at gcc dot gnu.org
Target Milestone|--- |9.2
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Before combine we have:
(insn 12 11 14 3 (set (zero_extract:DI (reg/v:DI 95 [ c ])
(const_int 32 [0x20])
(const_int 32 [0x20]))
(reg:DI 100)) "rh1727453.i":18:12 782 {*insv_regdi}
(expr_list:REG_DEAD (reg:DI 100)
(nil)))
(insn 14 12 15 3 (set (reg/v:DI 1 x1 [ e ])
(reg:DI 92 [ b$h ])) "rh1727453.i":4:17 47 {*movdi_aarch64}
(expr_list:REG_DEAD (reg:DI 92 [ b$h ])
(nil)))
(insn 15 14 16 3 (set (reg/v:DI 2 x2 [ f ])
(reg/v:DI 95 [ c ])) "rh1727453.i":5:17 47 {*movdi_aarch64}
(expr_list:REG_DEAD (reg/v:DI 95 [ c ])
(nil)))
Combine makes it into:
(insn 14 12 15 3 (set (reg/v:DI 1 x1 [ e ])
(reg:DI 92 [ b$h ])) "rh1727453.i":4:17 47 {*movdi_aarch64}
(nil))
(insn 15 14 16 3 (set (reg/v:DI 2 x2 [ f ])
(ior:DI (and:DI (reg:DI 92 [ b$h ])
(const_int 4294967295 [0xffffffff]))
(ashift:DI (subreg:DI (reg:SI 99) 0)
(const_int 32 [0x20])))) "rh1727453.i":5:17 794
{*aarch64_bfidi4_noand}
(expr_list:REG_DEAD (reg:DI 92 [ b$h ])
(expr_list:REG_DEAD (reg:SI 99)
(nil))))
(note the hard reg output, but still no input).
But then something during IRA decides to replace that reg:DI 92 with reg:DI 1
x1:
(insn 14 12 15 3 (set (reg/v:DI 1 x1 [ e ])
(reg:DI 92 [ b$h ])) "rh1727453.i":4:17 47 {*movdi_aarch64}
(expr_list:REG_DEAD (reg:DI 92 [ b$h ])
(nil)))
(insn 15 14 16 3 (set (reg/v:DI 2 x2 [ f ])
(ior:DI (and:DI (reg/v:DI 1 x1 [ e ])
(const_int 4294967295 [0xffffffff]))
(ashift:DI (subreg:DI (reg:SI 99) 0)
(const_int 32 [0x20])))) "rh1727453.i":5:17 794
{*aarch64_bfidi4_noand}
(expr_list:REG_DEAD (reg:SI 99)
(nil)))
And LRA can't deal with that, because the pattern is:
(define_insn ("*aarch64_bfidi4_noand")
[
(set (match_operand:DI 0 ("register_operand") ("=r"))
(ior:DI (and:DI (match_operand:DI 1 ("register_operand") ("0"))
(match_operand:DI 2 ("const_int_operand") ("n")))
(ashift:DI (match_operand:DI 3 ("register_operand") ("r"))
(match_operand:DI 4 ("aarch64_simd_shift_imm_di") ("n")))))
] ("aarch64_masks_and_shift_for_bfi_p (DImode, UINTVAL (operands[2]),
UINTVAL (operands[4]),
HOST_WIDE_INT_M1U << UINTVAL
(operands[4]) )") ("*{
operands[5] = GEN_INT (GET_MODE_BITSIZE (DImode) - UINTVAL (operands[4]));
return "bfi\t%x0, %x3, %4, %5";
}")
[
(set_attr ("type") ("bfm"))
])
and thus wants LRA to reload the operand 1 into the same register as operand 0.
I think "register_operand" "=r" and "register_operand" "0" operands are
extremely common in all backends, so I don't see an obvious bug on the aarch64
backend size here.
Vlad, could you please have a look?
