On 10/9/23 14:36, Vineet Gupta wrote:
Hi Christoph,
On 10/9/23 12:06, Patrick O'Neill wrote:
Hi Vineet,
We're seeing a regression on all riscv targets after this patch:|
FAIL: gcc.target/riscv/xtheadcondmov-indirect.c -O2
check-function-bodies ConNmv_imm_imm_reg||
FAIL: gcc.target/riscv/xtheadcondmov-indirect.c -O3 -g
check-function-bodies ConNmv_imm_imm_reg
Debug log output:
body: \taddi a[0-9]+,a[0-9]+,-1000+
\tli a[0-9]+,9998336+
\taddi a[0-9]+,a[0-9]+,1664+
\tth.mveqz a[0-9]+,a[0-9]+,a[0-9]+
\tret
against: li a5,9998336
addi a4,a0,-1000
addi a0,a5,1664
th.mveqz a0,a1,a4
ret|
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/8
https://github.com/ewlu/riscv-gnu-toolchain/issues/286
It seems with my patch, exactly same instructions get out of order (for
-O2/-O3) tripping up the test results and differ from say O1 for exact
same build.
-O2 w/ patch
ConNmv_imm_imm_reg:
li a5,9998336
addi a4,a0,-1000
addi a0,a5,1664
th.mveqz a0,a1,a4
ret
-O1 w/ patch
ConNmv_imm_imm_reg:
addi a4,a0,-1000
li a5,9998336
addi a0,a5,1664
th.mveqz a0,a1,a4
ret
I'm not sure if there is an easy way to handle that.
Is there a real reason for testing the full sequences verbatim, or is
testing number of occurrences of th.mv{eqz,nez} enough.
It seems Jeff recently added -fno-sched-pressure to avoid similar issues
but that apparently is no longer sufficient.
I'd suggest doing a count test rather than an exact match.
Verify you get a single li, two addis and one th.mveqz
Jeff
