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)
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
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
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:
>>>
>>>
>> 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,
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
> >>
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
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
> 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
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
Robin Dapp via Gcc-patches writes:
> Hi,
>
> as Juzhe noticed in gcc.dg/pr92301.c there was still something missing in
> the last patch. The attached v2 makes sure we always have a COND_LEN
> operation
> before returning true and initializes len and bias even if they are unused.
>
>
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
Hi,
as Juzhe noticed in gcc.dg/pr92301.c there was still something missing in
the last patch. The attached v2 makes sure we always have a COND_LEN operation
before returning true and initializes len and bias even if they are unused.
Bootstrapped and regtested on aarch64 and x86.
Regards
Robin
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
15 matches
Mail list logo
