On 9/18/23 13:45, Vineet Gupta wrote:
Hi Jeff, Andrew
I've been looking into redundant sign extension and while there are
things to be improved in REE, there's something I wanted to confirm
before heading off into the weeds.
Consider the test below:
int foo(int unused, int n, unsigned y, unsigned delta){
int s = 0;
unsigned int x = 0; // if int, sext elided
for (;x<n;x +=delta)
s += x+y;
return s;
}
-O2 -march=rv64gc_zba_zbb_zbs
foo2:
sext.w a6,a1 # 1
beq a1,zero,.L4
li a5,0
li a0,0
.L3:
addw a4,a2,a5
addw a5,a3,a5
addw a0,a4,a0
bltu a5,a6,.L3
ret
.L4:
li a0,0
ret
I believe the SEXT.W is not semantically needed as a1 is supposed to be
sign extended already at call site as per psABI [1]. I quote
"When passed in registers or on the stack, integer scalars narrower
than XLEN bits are widened according to the sign of their type up to 32
bits, then sign-extended to XLEN bits"
That's my understanding. We can (and should) assume that a sub-word
argument has been properly sign extended to XLEN.
However currently RISC-V backend thinks otherwise: changing @x to int,
causes the the sign extend to go away. I think both the cases should
behave the same (and not generate SEXT.w) given the ABI clause above.
Note that this manifests in initial RTL expand itself
generating/or-not-generating the sign_extend so if it is unnecessary we
can avoid late fixups in REE.
So for parameters I think there are knobs that we can set in the target
files to indicate they're extended/promoted. TARGET_PROMOTE_PROTOTYPES
would be a good search term I think. I don't think it's a heavily used
feature, so we may need to beat on it a little to get it to do what we want.
Jeff
