On 4/2/25 1:01 AM, Jin Ma wrote:
Assuming we have the following variables:
unsigned long long a0, a1;
unsigned int a2;
For the expression:
a0 = (a0 << 50) >> 49; // slli a0, a0, 50 + srli a0, a0, 49
a2 = a1 + a0; // addw a2, a1, a0 + slli a2, a2, 32 + srli a2, a2, 32
In the optimization process of ZBA (combine pass), it would be optimized to:
a2 = a0 << 1 + a1; // sh1add a2, a0, a1 + zext.w a2, a2
This is clearly incorrect, as it overlooks the fact that a0=a0&0x7ffe, meaning
that the bits a0[32:14] are set to zero.
gcc/ChangeLog:
* config/riscv/bitmanip.md: The optimization can only be applied if
the high bit of operands[3] is set to 1.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zba-shNadd-09.c: New test.
* gcc.target/riscv/zba-shNadd-10.c: New test.
Thanks.
While there isn't a regression bug in bugzilla, this is almost certainly
a 13, 14, 15 regression since the problematic pattern was integrated in
late 2022.
With that in mind, I went ahead and pushed this to the trunk.
Thanks again!
jeff
