Jeff Law writes:
> On 8/22/23 02:08, juzhe.zh...@rivai.ai wrote:
>> Yes, I agree long-term we want every-thing be optimized as early as
>> possible.
>>
>> However, IMHO, it's impossible we can support every conditional patterns
>> in the middle-end (match.pd).
>> It's a really big number.
>>
Hi Robin,
Thanks for these nice comments!
- emit_insn (gen_vcond_mask (vmode, vmode, d->target, d->op0, d->op1, mask));
+ /* swap op0 and op1 since the order is opposite to pred_merge. */
+ rtx ops2[] = {d->target, d->op1, d->op0, mask};
+ emit_vlmax_merge_insn (code_for_pred_merge
Hi Lehua,
no concerns here, just tiny remarks but in general LGTM as is.
> +(define_insn_and_split "*copysign_neg"
> + [(set (match_operand:VF 0 "register_operand")
> +(neg:VF
> + (unspec:VF [
> +(match_operand:VF 1 "register_operand")
> +
er
Subject: Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns
On 8/22/23 02:08, juzhe.zh...@rivai.ai wrote:
> Yes, I agree long-term we want every-thing be optimized as early as
> possible.
>
> However, IMHO, it's impossible we can support every condition
On 8/22/23 02:08, juzhe.zh...@rivai.ai wrote:
Yes, I agree long-term we want every-thing be optimized as early as
possible.
However, IMHO, it's impossible we can support every conditional patterns
in the middle-end (match.pd).
It's a really big number.
For example, for sign_extend
eil, floor,
etc.
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-22 15:33
To: juzhe.zhong; Andrew Pinski
CC: rdapp.gcc; Lehua Ding; gcc-patches@gcc.gnu.org; kito.ch...@gmail.com;
pal...@rivosinc.com; jeffreya...@gmail.com
Subject: Re: [PATCH] RISC-V: Add conditional unary neg/ab
> What about conditional zero_extension, sign_extension,
> float_extension, ...etc?
>
> We have discussed this, we can have some many conditional situations
> that can be supported by either match.pd or rtl backend combine
> pass.
>
> IMHO, it will be too many optabs/internal fns if we support
On Mon, Aug 21, 2023 at 10:42 PM Lehua Ding wrote:
>
> Hi,
>
> This patch add conditional unary neg/abs/not autovec patterns to RISC-V
> backend.
> Consider this C code:
>
> void
> test_3 (float *__restrict a, float *__restrict b, int *__restrict pred, int n)
>
Hi,
This patch add conditional unary neg/abs/not autovec patterns to RISC-V backend.
Consider this C code:
void
test_3 (float *__restrict a, float *__restrict b, int *__restrict pred, int n)
{
for (int i = 0; i < n; i += 1)
{
a[i] = pred[i] ? __builtin_fabsf (b[i]) :
