https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128466
Bug ID: 128466
Summary: Revisit selection of 32 bit values on rv64
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Target: riscv64
In the past we shelved this problem because of problems with extensions.
Essentially if we use addw to do the select, then we have to ensure that both
values we select across have been extended.
But if we know both arms are sign extended, then we can still use those kinds
of sequences.
Let's take this:
int
f (long c, int k, int a, int b, int *p)
{
int x = 4 >> k;
int y = (a << 4) >> b;
int s = x + y;
*p = s;
return c ? s : y;
}
That currently generates something like this:
sraw a3,a2,a3
sraw a1,a5,a1
addw t0,a1,a3
czero.eqz t1,t0,a0
czero.nez a0,a3,a0
sw t0,0(a4)
add a0,t1,a0
Since both operands we're selecting across are sign extended, we can turn it
into a conditional sign extending add with a single czero. Something like
this:
sraw a3,a2,a3
sraw a1,a5,a1
addw t0,a1,a3
czero.eqz t1,a1,a0
addw a0,t1,a3
sw t0,0(a4)
Rough estimate is this would save 10M instructions from the sample x264 I've
got. But I've seen this showing up elsewhere too (leela IIRC).
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2026, 2k17, 2k and 2k6 and
95)
