> What this means is is that you'll have to do the widening operations in
> the RISC-V expander. Essentially for an argument smaller than word_mode
> you'd want to widen to word_mode while retaining the right semantics.
Got it, I think it is the most different part between the scalar and vector
expander.
Back to this patch, looks for now we can only leverage gen_lowpart to perform
the widen for the right stmt.
If so and my understanding is correct, I will rebase this patch in v3.
Pan
-----Original Message-----
From: Jeff Law <jeffreya...@gmail.com>
Sent: Tuesday, July 9, 2024 4:44 AM
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/3/24 8:07 PM, Li, Pan2 wrote:
>> But if you look at what the hardware can actually support, it doesn't
>> have HImode or QImode operations other than load/store and for rv64
>> there are no SImode logicals.
>
>> That's what WORD_REGISTER_OPERATIONS is designed to support. Regardless
>> of what happens at the source level, the generic parts of gimple->RTL
>> expansion arrange to widen the types appropriately.
>
>> I haven't looked at the expansion of the SAT_* builtins, but the way
>> this is generally supposed to work is you just have to have your
>> expander only accept the modes the processor actually supports and
>> generic code will handle the widening for you.
>
> Thanks Jeff.
> Got it, you mean the widening ops will be covered automatically before
> expanding.
That's what happens for most basic operations. The caveat here is
you're not going to be going through the standard expander paths. It's
one of the unfortunate downsides of builtins/intrinsics, so we may need
to do something a bit special as a result.
> I am not sure which part take care auto-widening, but the SAT_TRUNC expands
> from middle end may look
> like below.
>
> Could you please help to enlighten me is there something missing here ?
>
> static void
> match_unsigned_saturation_trunc (gimple_stmt_iterator *gsi, gassign *stmt)
> {
> tree ops[1];
> tree lhs = gimple_assign_lhs (stmt);
> tree type = TREE_TYPE (lhs);
>
> if (gimple_unsigned_integer_sat_trunc (lhs, ops, NULL)
> && direct_internal_fn_supported_p (IFN_SAT_TRUNC,
> tree_pair (type, TREE_TYPE (ops[0])),
> OPTIMIZE_FOR_BOTH))
> {
> gcall *call = gimple_build_call_internal (IFN_SAT_TRUNC, 1, ops[0]);
> gimple_call_set_lhs (call, lhs);
> gsi_replace (gsi, call, /* update_eh_info */ true);
> }
> }
Right. That's what I was worried about. It essentially just asks the
backend "do you have this operation with this set of modes" without any
of the widening bits like you'd find in expand_binop.
We ran into this with the CRC work as well.
What this means is is that you'll have to do the widening operations in
the RISC-V expander. Essentially for an argument smaller than word_mode
you'd want to widen to word_mode while retaining the right semantics.
jeff
