On 8/13/24 10:16 PM, Li, Pan2 wrote:
How specifically is it avoided for SI? ISTM it should have the exact
same problem with a constant like 0x80000000 in SImode on rv64 which is
going to be extended to 0xffffffff80000000.
HI and QI need some special handling for sum. For example, for HImode.
65535 + 2 = 65537, when compare sum and 2, we need to cleanup the high bits
(aka make 65537 become 1) to tell the HImode overflow.
Thus, for HI and QI, we need to clean up highest bits of mode.
But for SI, we don't need that as we have addw insn, the sign extend will take
care of this as well as the sltu. For example, SImode.
lw a1,0(a5) // a1 is -40, aka 0xffffffffffffffd8
lui a0,0x1a //
addwi a5,a1,9 // a5 is -31, aka 0xffffffffffffffe1
// For QI and HI, we need to mask the highbits, but
not applicable for SI.
sltu a1,a5,a1 // compare a1 and a5, a5 > a1, then no-overflow as expected.
What's more important is that we get the RTL semantics right, the fact
that it seems to work due to addiw seems to be more of an accident than
by design. Also note that addiw isn't available unless ZBA is enabled,
so we don't want to depend on that to save us.
I still think we should be handling SI on rv64 in a manner similar to
QI/HI are handled on rv32/rv64.
jeff
