[Bug target/113035] New: RISC-V: -mtune=sifive-7-series additional dump failures found with bitmanip, zicond, and vector targets

[Bug target/113035] New: RISC-V: -mtune=sifive-7-series additional dump failures found with bitmanip, zicond, and vector targets

[ewlu at rivosinc dot com]

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

            Bug ID: 113035
           Summary: RISC-V: -mtune=sifive-7-series additional dump
                    failures found with bitmanip, zicond, and vector
                    targets
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

Created attachment 56888
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56888&action=edit
testsuite failures for rv64 bitmanip and vector as of r14-6557-g767e2674875

I was testing different cpu/tunes for cleaning up the scheduler and saw that
there are significant differences in testsuite results between using
mtune=rocket (default) and mtune=sifive-7-series. 

Most notably, there are many failures in gcc.target/riscv/rvv/vsetvl,
gcc.target/riscv/zicond-primitiveSemantics_compare_*.c, and some with zbb and
zbs.

Full log output included in attachment

Configuration:
   
riscv-sim/-march=rv64gc_zba_zbb_zbc_zbs/-mabi=lp64d/-mtune=sifive-7-series/-mcpu=sifive-u74/-mcmodel=medlow
   
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mtune=sifive-7-series/-mcpu=sifive-u74/-mcmodel=medlow

[Bug target/113035] RISC-V: -mtune=sifive-7-series additional dump failures found with bitmanip, zicond, and vector targets

[ewlu at rivosinc dot com]

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

--- Comment #1 from Edwin Lu <ewlu at rivosinc dot com> ---
Created attachment 57106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57106&action=edit
testsuite failures for rv64 bitmanip and vector as of r14-7474-g7d8de1ca4a7

Double checked for execution failures on linux rv64gcv with
-mtune=sifive-7-series as discussed in today's meeting. No unexpected execution
failures as of r14-7474-g7d8de1ca4a7

Config:
Schedule of variations:
    riscv-sim/-march=rv64gcv/-mabi=lp64d/-mtune=sifive-7-series/-mcmodel=medlow

[Bug target/113035] RISC-V: regression testsuite errors -mtune=sifive-7-series

[Dusan.Stojkovic@rt-rk.com]

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

Dusan Stojkovic <Dusan.Stojkovic@rt-rk.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Dusan.Stojkovic@rt-rk.com

--- Comment #2 from Dusan Stojkovic <Dusan.Stojkovic@rt-rk.com> ---
Hello,

During our investigation into this bug, we discovered that it is triggered by
the -O2 optimization flag, specifically by the -fschedule-insns and
`-fschedule-insns2` options in most test cases we analyzed. These scheduler
optimizations rearrange the instructions in a way that causes the tests to
fail. For the rocket mtune option, however, this rearrangement does not occur
in a manner that causes test failures.

To be more specific, we have confirmed this issue with some of the
`vlmax_bb_prop-*.c` test cases. For instance, in the case of
`vlmax_bb_prop-24.c`, the assembly output differs between rocket and SiFive as
follows:

- Rocket assembly output - (https://godbolt.org/z/z4c1enbx5)
- SiFive assembly output - (https://godbolt.org/z/s8ch6Tn7W)

Let's consider the first failing pattern from the test:
{vsetvli\s+[a-x0-9]+,\s*zero,\s*e8,\s*mf8,\s*t[au],\s*m[au]\s+\.L[0-9]\:} 1

For the mtune=rocket, with `-O2` optimization, the output is:
...
vsetvli a5,zero,e8,mf8,ta,ma
.L5:
...

For the mtune=sifive-7-series, with `-O2` optimization, the assembly output is:
...
vsetvli a5,zero,e8,mf8,ta,ma
add a4,a0,a2
.L5:
...

The extra `add` instruction in the SiFive output prevents the pattern from
matching, causing the test to fail.

Possible mitigations for this issue, similar to those mentioned in the bug
report (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249), include:
- Disabling the scheduler with the following options:
  /* { dg-additional-options "-fno-schedule-insns -fno-schedule-insns2" } */
- Removing the `-O2` optimization flag by adding the option -no-opts "-O2" to
the failing tests.

Configuration:
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mtune=sifive-7-series/-mcmodel=medlow

[Bug target/113035] RISC-V: regression testsuite errors -mtune=sifive-7-series

[Dusan.Stojkovic@rt-rk.com]

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

--- Comment #3 from Dusan Stojkovic <Dusan.Stojkovic@rt-rk.com> ---
Upon further investigation into the bug related to the vsetvl-*.c tests
(specifically vsetvl-13.c, vsetvl-15.c, and vsetvl-23.c), we found the
following:

When using the mtune=sifive-7-series tuning, tests fail due to a different
number of vsetvli instructions, with the expected format, in the compiler
assembly output compared to mtune=rocket.

For example, the test vsetvl-13.c has the following pattern:
/* { dg-final { scan-assembler-times
{vsetvli\s+zero,\s*[a-x0-9]+,\s*e32,\s*m1,\s*tu,\s*m[au]} 2 { target { no-opts
"-O0" no-opts "-g" no-opts "-funroll-loops" } } } } */

This pattern expects two vsetvli instructions in the given format. With
mtune=rocket, and -O2 optimization, the test passes because it generates the
following instructions:
vsetvli zero,a6,e32,m1,tu,ma
vsetvli zero,a7,e32,m1,tu,ma

However, with mtune=sifive-7-series, the compiler generates only one
instruction (since it uses the movcc transformation):
vsetvli zero,a6,e32,m1,tu,ma

Since the pattern requires two instructions to match, the test fails for
sifive-7-series.

If we assume that the generated code works correctly as is, a reasonable
solution would be to have two separate tests: one for sifive-7-series, where
the expected number of matches is 1, and the original test for other mtune
settings.

Here’s the generated assembly code for reference:
- With mtune=sifive-7-series: https://godbolt.org/z/hPcT7e3Gd
- With mtune=rocket: https://godbolt.org/z/v59TYTfPa

Configurations:
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mtune=rocket/-mcmodel=medlow
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mtune=sifive-7-series/-mcmodel=medlow

[Bug target/113035] RISC-V: regression testsuite errors -mtune=sifive-7-series

[law at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Thanks!  It actually looks like there's two vsetvls in both output files.  But
in the case of the sifive-7 tuning, the two vsetvls set different vector
configurations.

for sifive-7 we have these:

vsetvli a6,a6,e8,mf4,ta,ma
vsetvli zero,a6,e32,m1,tu,ma

While rocket tuning gives us:

vsetvli zero,a6,e32,m1,tu,ma
vsetvli zero,a7,e32,m1,tu,ma


At first glance it looks like the vsetvl pass failed to unify the two vector
configurations for the sifive-7 case.  So that's probably the place to look
(sigh, it's a fairly complex hunk of code and won't be trivial to
understand/fix).


Jeff