[Bug c/115478] New: [15 Regression] gcc.target/aarch64/bitint-args.c fails

[Bug c/115478] New: [15 Regression] gcc.target/aarch64/bitint-args.c fails

[carlos.seo at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478

            Bug ID: 115478
           Summary: [15 Regression] gcc.target/aarch64/bitint-args.c fails
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: carlos.seo at linaro dot org
  Target Milestone: ---

With patch 2277f987979445f4390a5c6e092d79e04814d641, the testcases
(check-function-bodies f65 | check-function-bodies f127) in
gcc.target/aarch64/bitint-args.c need to be adjusted.

body: \textr    (x[0-9]+), x3, x2, 1
\tand   (x[0-9]+), x2, 1
\torr   (x[0-9]+), \2, \1, lsl 1
\tasr   (x[0-9]+), \1, 63
\tstp   \3, \4, \[x0\]
\tret

against:        lsl     x3, x3, 63
        add     x3, x3, x2, lsr 1
        and     x2, x2, 1
        add     x2, x2, x3, lsl 1
        asr     x3, x3, 63
        stp     x2, x3, [x0]
        ret

FAIL: gcc.target/aarch64/bitint-args.c check-function-bodies f65

body: \textr    (x[0-9]+), x3, x2, 63
\tand   (x[0-9]+), x2, 9223372036854775807
\torr   (x[0-9]+), \2, \1, lsl 63
\tasr   (x[0-9]+), \1, 1
\tstp   \3, \4, \[x0\]
\tret

against:        lsl     x3, x3, 1
        add     x3, x3, x2, lsr 63
        and     x2, x2, 9223372036854775807
        add     x2, x2, x3, lsl 63
        asr     x3, x3, 1
        stp     x2, x3, [x0]
        ret

FAIL: gcc.target/aarch64/bitint-args.c check-function-bodies f127

[Bug c/115478] [15 Regression] gcc.target/aarch64/bitint-args.c fails

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
r15-1120-g2277f987979445

[Bug target/115478] [15 Regression] gcc.target/aarch64/bitint-args.c fails

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at nextmovesoftware dot com
          Component|c                           |target
             Target|                            |aarch64
           Keywords|                            |missed-optimization
   Target Milestone|---                         |15.0

[Bug target/115478] [15 Regression] gcc.target/aarch64/bitint-args.c fails

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |law at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-06-13

--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Those look worse than the original, so I don't think we want to blindly change
the expected output.  We need to understand the delta a bit better.

My suspicion is we had a combiner pattern in the aarch64 backend that triggered
on the old (unsimplified) form which doesn't after the RTL simplifications. 
It's on my list, but I haven't gotten to it yet.

[Bug target/115478] [15 Regression] gcc.target/aarch64/bitint-args.c fails

[roger at nextmovesoftware dot com]

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].

[Bug target/115478] [15 Regression] gcc.target/aarch64/bitint-args.c fails

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478

--- Comment #4 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Roger, that looks pretty reasonable.  I suspect we're going to need to do
something similar for the sh port which seems to be affected negatively as
well.

[Bug target/115478] [15 Regression] gcc.target/aarch64/bitint-args.c fails since r15-1120-g2277f987979445

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478

Richard Sandiford <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #5 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
How about adding a new match_operator predicate to common.md for this kind of
situation?  It would be nice if it could automatically detect when the two
operands have no nonzero bits in common, but doing that would need some
refactoring of the nonzero_bits code, to ensure that the predicate gives a
consistent result (and does that without polluting the current nonzero_bits
cache).

In the meantime, it might be enough to say that the insn must enforce the
non-overlapping bits check itself.