Hi Jeff,
Thank you very much! I haven't tried RTL test yet and it sounds interesting and
I would try to make one, thanks for guidance :)
And sorry I didn't mentioned that I have tried to run the risk.exp test suite
(on riscv64-unknown-linux-gnu) and found no new failures.
Best,
Luke Zhuang
------------------------------------------------------------------
From:Jeffrey Law <[email protected]>
Send Time:Sun, Aug 23, 2026, 06:12
To:Luke Zhuang<[email protected]>;
"gcc-patches"<[email protected]>
CC:"kito.cheng"<[email protected]>; "rdapp.gcc"<[email protected]>;
palmer<[email protected]>; andrew<[email protected]>;
"jim.wilson.gcc"<[email protected]>;
"juzhe.zhong"<[email protected]>; rdsandiford<[email protected]>;
"zhuangzhi.zz"<[email protected]>
Subject:Re: [PATCH] RISC-V: Improve slliw shifted bitfield split constraints
On 8/21/2026 2:23 AM, Luke Zhuang wrote:
> From: "Luke Zhuang" <[email protected]>
>
> Improve the constraints in the split pattern introduced by
> <046bc3484c9>:
> 1. The split ought to only match bitfields starting at bit 0, as
> described in its commit message.
> 2. Need to make sure the hi-32bits of operands[5] is completely
> equivalent to signed extened slliw result after removing the
> outer AND
>
> Though the issues theoretically exist, I cannot find a C-level
> counterexample to demonstrate the issue. May add one if it's
> possible to make one in the future.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Restrict slliw shifted bitfield split
> to extractions starting at bit 0, and require the outer mask to
> match slliw sign-extension.
You might be able to generate a testcase using the framework that reads
RTL and starts the RTL optimization phase at combine. So you could in
theory set up the precise scenario where you have RTL which should
combine into this insn, but violating one or both of the issues you've
identified. If you look at the *-rtl files in
gcc/testsuite/gcc.target/riscv you should see the basics of how to set
things up.
You didn't mention how this was tested. For a target dependent patch
you should at least be running the full testsuite on that target to
verify there are no regressions. You could either run it natively on a
RISC-V system (painful due to current performance levels of RISC-V
designs) or you could test riscv32-elf or riscv64-elf. I went ahead and
tested it on both riscv64-elf for you.
Thanks for finding and fixing these oversights! I'm pushing your patch
to the trunk momentarily.
Jeff
