Robin Dapp writes:
> Thank you for the explanation.
>
> So, assuming I added an IFN_VCOND_MASK and IFN_VCOND_MASK_LEN along
> with the respective helper and expand functions, what would be the
> way forward?
IMO it'd be worth starting with the _LEN form only.
> Generate an IFN_VCOND_MASK(_LEN) h
Richard Biener writes:
> On Mon, Oct 16, 2023 at 11:59 PM Richard Sandiford
> wrote:
>>
>> Robin Dapp writes:
>> >> Why are the contents of this if statement wrong for COND_LEN?
>> >> If the "else" value doesn't matter, then the masked form can use
>> >> the "then" value for all elements. I wou
Thank you for the explanation.
So, assuming I added an IFN_VCOND_MASK and IFN_VCOND_MASK_LEN along
with the respective helper and expand functions, what would be the
way forward?
Generate an IFN_VCOND_MASK(_LEN) here instead of a VEC_COND_EXPR?
How would I make sure all of match.pd's vec_cond opt
Robin Dapp writes:
>>> I don't know much about valueisation either :) But it does feel
>>> like we're working around the lack of a LEN form of COND_EXPR.
>>> In other words, it seems odd that we can do:
>>>
>>> IFN_COND_LEN_ADD (mask, a, 0, b, len, bias)
>>>
>>> but we can't do:
>>>
>>> IFN_C
>> I don't know much about valueisation either :) But it does feel
>> like we're working around the lack of a LEN form of COND_EXPR.
>> In other words, it seems odd that we can do:
>>
>> IFN_COND_LEN_ADD (mask, a, 0, b, len, bias)
>>
>> but we can't do:
>>
>> IFN_COND_LEN (mask, a, b, len, bia
On Mon, Oct 16, 2023 at 11:59 PM Richard Sandiford
wrote:
>
> Robin Dapp writes:
> >> Why are the contents of this if statement wrong for COND_LEN?
> >> If the "else" value doesn't matter, then the masked form can use
> >> the "then" value for all elements. I would have expected the same
> >> th
Hi, Richard.
>> Does IFN_COND_LEN make conceptual sense on RVV? If so, would defining
>> it solve some of these problems?
Yes, IFN_COND_LEN make sense to RVV. We have vmerge instruction which depending
on VL/AVL.
I must say my internal RVV GCC has IFN_LEN_VCOND_MASK which simplify
COND_LEN_ADD
Robin Dapp writes:
>> Why are the contents of this if statement wrong for COND_LEN?
>> If the "else" value doesn't matter, then the masked form can use
>> the "then" value for all elements. I would have expected the same
>> thing to be true of COND_LEN.
>
> Right, that one was overly pessimistic.
> Why are the contents of this if statement wrong for COND_LEN?
> If the "else" value doesn't matter, then the masked form can use
> the "then" value for all elements. I would have expected the same
> thing to be true of COND_LEN.
Right, that one was overly pessimistic. Removed.
> But isn't the
Richard Sandiford writes:
> Robin Dapp via Gcc-patches writes:
>> [...]
>> @@ -386,9 +390,29 @@ try_conditional_simplification (internal_fn ifn,
>> gimple_match_op *res_op,
>> default:
>>gcc_unreachable ();
>> }
>> - *res_op = cond_op;
>> - maybe_resimplify_conditional_op (se
if they are unused.
>
> Bootstrapped and regtested on aarch64 and x86.
Sorry for the slow review. I was hoping Richi would take it,
but I see he was hoping the same from me.
> Regards
> Robin
>
> Subject: [PATCH v2] gimple-match: Do not try UNCOND optimization with
> COND_LEN.
>
>
Ping^2.
I realize it's not very elegant as of now. If there's a better/shorter way
to solve this feel free to suggest :)
Regards
Robin
Ping.
Regards
Robin
Thanks Robin for fixing it.
- : cond (cond_in), else_value (else_value_in)
+ : cond (cond_in), else_value (else_value_in), len (NULL_TREE),
+bias (NULL_TREE)It seems that you shouldn't include this fix in the patch?
+
+ if (len)
+{
+ /* If we had a COND_LEN before we need to ensure
Subject: [PATCH v2] gimple-match: Do not try UNCOND optimization with
COND_LEN.
On riscv we mis-optimize conditional (length) operations into
unconditional operations e.g. in slp-reduc-7.c and
gcc.dg/pr92301.c.
This patch prevents optimizing e.g.
COND_LEN_ADD ({-1, ... }, a, 0, c, len, bias
Hi,
found in slp-reduc-7.c, this patch prevents optimizing e.g.
COND_LEN_ADD ({-1, ... }, a, 0, c, len, bias)
unconditionally into just "a".
Currently, we assume that COND_LEN operations can be optimized similarly
to COND operations. As the length is part of the mask (and usually not
compile-ti
16 matches
Mail list logo
