[Bug target/101345] New: wrong code at -O1 with vector modulo

[Bug target/101345] New: wrong code at -O1 with vector modulo

[zsojka at seznam dot cz]

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

            Bug ID: 101345
           Summary: wrong code at -O1 with vector modulo
           Product: gcc
           Version: 12.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: powerpc64le-unknown-linux-gnu

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

Output:
$ powerpc64le-unknown-linux-gnu-gcc -O testcase.c -static
$ qemu-ppc64le -- ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

The value is 0x2828282828282828 instead of 0x1414141414141414
Already the computed value of "y" is wrong.

        subfic 10,10,4   # tmp160, tmp159,

looks wrong, if replaced by

        subfic 10,10,2   # tmp160, tmp159,

the code works correctly

$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-2049-20210706092228-gb019b28ebd6-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/12.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-2049-20210706092228-gb019b28ebd6-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210706 (experimental) (GCC)

[Bug target/101345] wrong code at -O1 with vector modulo

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
      Known to work|                            |13.0, 14.0
                 CC|                            |jeevitha at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
   Last reconfirmed|                            |2024-4-18

--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> ---
I can confirm the checkout used at the time
(b019b28ebd65462a092c96d95e9e356c8bb39b78) does produce "subfic rX,rX,4".  That
said, with commit b85e79dce149df68b92ef63ca2a40ff1dfa61396 (about the time
gcc13 branches), it is fixed to "subfic rX,rX,2", so I'm marking this as
RESOLVED/FIXED.  It remains fixed since that commit too.

Jeevitha, can you please do a git bisect from the two commits above to identify
the commit that fixes this for posterity sake?  Thanks.

[Bug target/101345] wrong code at -O1 with vector modulo

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #1)
> Jeevitha, can you please do a git bisect from the two commits above to
> identify the commit that fixes this for posterity sake?  Thanks.

I'll note I used -O1 -mcpu=power8 for my compiles.

[Bug target/101345] wrong code at -O1 with vector modulo

[jeevitha at gcc dot gnu.org]

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

--- Comment #3 from Jeevitha <jeevitha at gcc dot gnu.org> ---

> Jeevitha, can you please do a git bisect from the two commits above to
> identify the commit that fixes this for posterity sake?  Thanks.

The commit that resolved the incorrect code was
ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0, where Bill disabled the swap for mult
with subreg. This addressed the issue.

The reason behind this change is as follows:

The input for the swap pass is,

insn 23 set r144, vec_concat(r152,r160)
insn 26 set r162, r237*(r144+0)
insn 27 set r163, (r144+8)*r236
insn 29 set r166, r236*(r144+0)
insn 30 set r167, subreg(r236*(r144+0),8)


Output from swap pass is,

insn 23 set r144, vec_concat(r160,r152)
insn 26 set r162, r237*(r144+8)
insn 27 set r163, (r144+0)*r236
insn 29 set r166, r236*(r144+8)
insn 30 set r167, subreg(r236*(r144+8),0)

In the provided sample code, multiplication operations are performed. Here, the
SUBREG_BYTE changes in pseudo 144 are correct. However, the change from 8 to 0
in the SUBREG_BYTE of MULT(r236,r144) is incorrect. This alteration leads to
treating it as a low-part multiply ie, similar to insn 29, whereas it should
actually a high-part multiply. Therefore, Bill stopped the swap for mult with
subreg case, which resolves this issue.

To provide clear reference, here is the RTL for insn 30 in failure case:

(insn 30 29 31 2 (set (reg:DI 167)
        (subreg:DI (mult:TI (zero_extend:TI (reg:DI 236))
-              (zero_extend:TI (subreg:DI (reg:V2DI 144) 0))) 8))
"test1.c":13:5 166 {umuldi3_highpart_le} //input from swap pass
+               (zero_extend:TI (subreg:DI (reg:V2DI 144) 8))) 0))
"test1.c":13:5 166 
{umuldi3_highpart_le} //output from swap pass

[Bug target/101345] wrong code at -O1 with vector modulo

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |101129

--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jeevitha from comment #3)
> The commit that resolved the incorrect code was
> ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0, where Bill disabled the swap for
> mult with subreg. This addressed the issue.

Ok, so that was the fix for PR101129.

Thanks for tracking that down Jeevitha!


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129
[Bug 101129] [11/12 Regression] wrong code at -O1 since r11-5839