> 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.
Pan
-----Original Message-----
From: Jeff Law <jeffreya...@gmail.com>
Sent: Wednesday, August 14, 2024 12:03 PM
To: Li, Pan2 <pan2...@intel.com>; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp....@gmail.com
Subject: Re: [PATCH v2] RISC-V: Make sure high bits of usadd operands is clean
for HI/QI [PR116278]
On 8/12/24 8:09 PM, Li, Pan2 wrote:
>> Isn't this wrong for SImode on rv64? It seems to me the right test is
>> mode != word_mode?
>> Assuming that works, it's OK for the trunk.
>
> Thanks Jeff, Simode version of test file doesn't have this issue. Thus, only
> HI and QI here.
> I will add a new test for SImode in v3 to ensure this.
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.
Jeff
