Robin Dapp <rdapp....@gmail.com> 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) here instead of a VEC_COND_EXPR?
> How would I make sure all of match.pd's vec_cond optimizations
> applied to it as well?
I think the most important ones are:
/* Simplify:
a = a1 op a2
r = c ? a : b;
to:
r = c ? a1 op a2 : b;
if the target can do it in one go. This makes the operation conditional
on c, so could drop potentially-trapping arithmetic, but that's a valid
simplification if the result of the operation isn't needed.
Avoid speculatively generating a stand-alone vector comparison
on targets that might not support them. Any target implementing
conditional internal functions must support the same comparisons
inside and outside a VEC_COND_EXPR. */
It would be nice if there was some match.pd syntax that automatically
extended these rules to IFN_VCOND_MASK_LEN, but I don't know how easy
that would be, due to the extra two parameters.
Perhaps that itself could be done in gimple-match-exports.cc, in a similar
way to the current conditional stuff. That is:
- for IFN_VCOND_MASK_LEN, try folding as a VEC_COND_EXPR and then "adding
the length back"
- for IFN_COND_LEN_FOO, try folding as an IFN_COND_FOO and then
"add the length back"
Not sure how important the second one is.
Thanks,
Richard
> Right now AFAIK IFN_VCOND_MASK only gets created in isel and
> everything is just a VEC_COND before. But that does not provide
> length masking so is not the way to go?
>
> Thanks.
>
> Regards
> Robin
