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
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
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.
>
> Bootstrapped
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
13 matches
Mail list logo
