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

--- Comment #3 from Dusan Stojkovic <dusan.stojko...@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

Reply via email to