Thanks Jeff and waterman for comments.
> 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.
The SImode has different handling from day 1 which follow the algorithm up to a
point.
11842 if (mode == SImode && mode != Xmode)
11843 { /* Take addw to avoid the sum truncate.
11844 rtx simode_sum = gen_reg_rtx (SImode
11845 riscv_emit_binary (PLUS, simode_sum, x, y
11846 emit_move_insn (xmode_sum, gen_lowpart (Xmode, simode_sum));
11847 }
> I think your overall point still holds, though.
Got the point here but I would like to double confirm the below 2 more insn is
acceptable for this change. (or we can eliminate it later)
sat_u_add_uint32_t_fmt_1:
slli a5,a0,32 // additional insn for taking care SI in rv64
srli a5,a5,32 // Ditto.
addw a0,a0,a1
sltu a5,a0,a5
neg a5,a5
or a0,a5,a0
sext.w a0,a0
ret
If so, I will prepare the v3 for the SImode in RV64.
Pan
-----Original Message-----
From: Andrew Waterman <and...@sifive.com>
Sent: Friday, August 16, 2024 12:28 PM
To: Jeff Law <jeffreya...@gmail.com>
Cc: Li, Pan2 <pan2...@intel.com>; gcc-patches@gcc.gnu.org;
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 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
>
