On Thu, Aug 15, 2024 at 9:23 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > 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.
addiw is always available in RV64; you're probably thinking of add.uw, which is an RV64_Zba instruction. I think your overall point still holds, though. > > I still think we should be handling SI on rv64 in a manner similar to > QI/HI are handled on rv32/rv64. > > jeff >
