https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113035
Dusan Stojkovic <dusan.stojko...@rt-rk.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dusan.stojko...@rt-rk.com
--- Comment #2 from Dusan Stojkovic <dusan.stojko...@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
