[Bug target/106273] New: [13 Regression] wrong code with -Og -march=cascadelake (due to ANDN?)

[Bug target/106273] New: [13 Regression] wrong code with -Og -march=cascadelake (due to ANDN?)

[zsojka at seznam dot cz]

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

            Bug ID: 106273
           Summary: [13 Regression] wrong code with -Og -march=cascadelake
                    (due to ANDN?)
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

Created attachment 53292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53292&action=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -Og -march=cascadelake testcase.c
$ ./a.out 
Aborted

The value is 10 instead of 5.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1649-20220712164051-gcab411a2b4b-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1649-20220712164051-gcab411a2b4b-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220712 (experimental) (GCC)

[Bug target/106273] [13 Regression] wrong code with -Og -march=cascadelake (due to ANDN?)

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug target/106273] [13 Regression] wrong code with -Og -march=cascadelake (due to ANDN?) since r13-1379-ge8a46e5cdab500ea

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Keywords|needs-bisection             |
           Priority|P3                          |P1
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |sayle at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org
            Summary|[13 Regression] wrong code  |[13 Regression] wrong code
                   |with -Og -march=cascadelake |with -Og -march=cascadelake
                   |(due to ANDN?)              |(due to ANDN?) since
                   |                            |r13-1379-ge8a46e5cdab500ea
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-07-13

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r13-1379-ge8a46e5cdab500ea.

[Bug target/106273] [13 Regression] wrong code with -Og -march=cascadelake (due to ANDN?) since r13-1379-ge8a46e5cdab500ea

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |roger at nextmovesoftware dot com
                 CC|                            |roger at nextmovesoftware dot com
             Status|NEW                         |ASSIGNED

--- Comment #2 from Roger Sayle <roger at nextmovesoftware dot com> ---
Mine.  The *andn<dwi>4_doubleword_bmi post-reload splitter needs an
early-clobber constraint during register allocation.  I'm bootstrapping and
regression testing a fix.

[Bug target/106273] [13 Regression] wrong code with -Og -march=cascadelake (due to ANDN?) since r13-1379-ge8a46e5cdab500ea

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:fd3d25d6df1cbd385d2834ff3059dfb6905dd75c

commit r13-1716-gfd3d25d6df1cbd385d2834ff3059dfb6905dd75c
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Fri Jul 15 22:48:56 2022 +0100

    PR target/106273: Add earlyclobber to *andn<dwi>3_doubleword_bmi on x86_64.

    This patch resolves PR target/106273 which is a wrong code regression
    caused by the recent reorganization to split doubleword operations after
    reload on x86.  For the failing test case, the constraints on the
    andnti3_doubleword_bmi pattern allow reload to allocate the output and
    operand in overlapping but non-identical registers, i.e.

    (insn 45 44 66 2 (parallel [
                (set (reg/v:TI 5 di [orig:96 i ] [96])
                    (and:TI (not:TI (reg:TI 39 r11 [orig:83 _2 ] [83]))
                        (reg/v:TI 4 si [orig:100 i ] [100])))
                (clobber (reg:CC 17 flags))
            ]) "pr106273.c":13:5 562 {*andnti3_doubleword_bmi}

    where the output is in registers 5 and 6, and the second operand is
    registers 4 and 5, which then leads to the incorrect split:

    (insn 113 44 114 2 (parallel [
                (set (reg:DI 5 di [orig:96 i ] [96])
                    (and:DI (not:DI (reg:DI 39 r11 [orig:83 _2 ] [83]))
                        (reg:DI 4 si [orig:100 i ] [100])))
                (clobber (reg:CC 17 flags))
            ]) "pr106273.c":13:5 566 {*andndi_1}

    (insn 114 113 66 2 (parallel [
                (set (reg:DI 6 bp [ i+8 ])
                    (and:DI (not:DI (reg:DI 40 r12 [ _2+8 ]))
                        (reg:DI 5 di [ i+8 ])))
                (clobber (reg:CC 17 flags))
            ]) "pr106273.c":13:5 566 {*andndi_1}

    [Notice that reg:DI 5 is set in the first instruction, but assumed
    to have its original value in the second].  My first thought was
    that this could be fixed by swapping the order of the split instructions
    (which works in this case), but in the general case, it's impossible
    to handle (set (reg:TI x) (op (reg:TI x+1) (reg:TI x-1)).  Hence for
    correctness this pattern needs an earlyclobber "=&r", but we can also
    allow cases where the output is the same as one of the operands (using
    constraint "0").  The other binary logic operations (AND, IOR, XOR)
    are unaffected as they constrain the output to match the first
    operand, but BMI's andn is a three-operand instruction which can
    lead to the overlapping cases described above.

    2022-07-15  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR target/106273
            * config/i386/i386.md (*andn<dwi>3_doubleword_bmi): Update the
            constraints to reflect the output is earlyclobber, unless it is
            the same register (pair) as one of the operands.

    gcc/testsuite/ChangeLog
            PR target/106273
            * gcc.target/i386/pr106273.c: New test case.

[Bug target/106273] [13 Regression] wrong code with -Og -march=cascadelake (due to ANDN?) since r13-1379-ge8a46e5cdab500ea

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Roger Sayle <roger at nextmovesoftware dot com> ---
This should now be fixed.