https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478
--- Comment #3 from Roger Sayle <roger at nextmovesoftware dot com> ---
Hi Jeff, many thanks for looking into this/assigning the PR to yourself.
I'd suggest that the fix is to add a define_code_iterator to aarch64.md
called any_or_plus matching the definition in i386.md.
(define_code_iterator any_or_plus [plus ior xor])
that can then be used (in place of ior) in the definition of *extr<mode>5_insn
and friends.
(define_insn "*extr<mode>5_insn"
[(set (match_operand:GPI 0 "register_operand" "=r")
(<any_or_plus>:GPI (ashift:GPI (match_operand:GPI 1 "register_operand" "r")
(match_operand 3 "const_int_operand" "n"))
(lshiftrt:GPI (match_operand:GPI 2 "register_operand" "r")
(match_operand 4 "const_int_operand" "n"))))]
"UINTVAL (operands[3]) < GET_MODE_BITSIZE (<MODE>mode) &&
(UINTVAL (operands[3]) + UINTVAL (operands[4]) == GET_MODE_BITSIZE
(<MODE>mode))"
"extr\\t%<w>0, %<w>1, %<w>2, %4"
[(set_attr "type" "rotate_imm")]
)
Likewise for:
(define_insn "*extr<mode>5_insn_alt"
(define_insn "*extrsi5_insn_uxtw"
(define_insn "*extrsi5_insn_uxtw_alt"
(define_insn "*extrsi5_insn_di"
Technically, this was previously a missed optimization where the PLUS and XOR
forms wouldn't be optimized.
Sorry, the server I normally use to build cross-compilers (to aarch64) is down
at the moment, so I've been taking longer to investigate this than usual.
Thanks to Carlos for filing a PR, indicating what the failure is [that's helped
a lot].
