Thanks Jeff for comments.
> I would expect that QI/HI shouldn't be happening in practice due to the
> definition of WORD_REGISTER_OPERATIONS.
Sorry I don't get the point here, I suppose there may be 6 kinds of truncation
for scalar.
uint64_t => uint32_t
uint64_t => uint16_t
uint64_t => uint8_t
uint32_t => uint16_t
uint32_t => uint8_t
uint16_t => uint8_t
Take uint16_t to uint8_t as example:
uint8_t test (uint16_t x)
{
bool overflow = x > (uint16_t)(uint8_t)(-1);
return ((uint8_t)x) | (uint8_t)-overflow;
}
Will be expand to:
uint8_t sat_u_truc_uint16_t_to_uint8_t_fmt_1 (uint16_t x)
{
uint8_t _6;
_6 = .SAT_TRUNC (x_4(D)); [tail call]
return _6;
}
Then we will have HImode as src and the QImode as the dest when enter
riscv_expand_ustrunc.
Pan
-----Original Message-----
From: Jeff Law <jeffreya...@gmail.com>
Sent: Wednesday, July 3, 2024 11:14 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: Implement the .SAT_TRUNC for scalar
On 7/2/24 7:16 PM, Li, Pan2 wrote:
> Thanks Jeff for comments.
>
>> Why are you using Pmode? Pmode is for pointers. This stuff looks like
>> basic integer ops, so I don't see why Pmode is appropriate.
>
> The incoming operand may be HI/QI/SImode, so we need to prompt the mode.
> So there we should take Xmode? Will update in v2.
I would expect that QI/HI shouldn't be happening in practice due to the
definition of WORD_REGISTER_OPERATIONS.
For rv32 I would expect to just see SI. For rv64 we're likely to see
both SI and DI and I would expect that you can just use GET_MODE (src)
to get that input mode -- unless the input is a constant.
Note that since you're ultimately generating an IOR, if you've got an SI
input on rv64, then you're going to need to either extend the input or
wrap it in a suitable widening subreg.
If we allow constants, then we probably need further adjustments.
Jeff
