https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
> We can't ignore them unless VEC_COND_EXPR lowering will process them.
> That is, we have to check whether we can expand all instances of the
> compares. This basically means we need to run "isel" on them but
> not actually commit the IL change but instead lower all cases we
> could not process. The question is what to do about for example
>
> _34 = vect__1.7_28 == vect__3.11_33;
> vect_iftmp.12_35 = VEC_COND_EXPR <_34, vect__1.7_28, vect__2.10_31>;
> foo (_34);
>
> where we can ISEL the VEC_COND_EXPR together with _34 but _34 is
> live anyway. Do we want to both lower _34 (for the use in foo)
> and keep it (for the purpose of VEC_COND_EXPR expansion)?
Likely not as seen in PR95745 where a "temporary" tmp = A == B is not
guaranteed to be expandable and so we purge it.
> I guess so.
> OTOH if the target an expand VEC_COND_EXPR <_1 == _2, ...>
> then it can expand _1 == _2 as VEC_COND_EXPR <_1 == _2, {-1,-1,-1},
> {0,0,0}> so this is exactly the case why I thought applying ISEL
> on both together makes sense. Looks like it actually happens ...
>
> Which means we don't actually need to lower the compare since
> we can expand it as VEC_COND_EXPR?
Yes, I would recommend skipping lowering of all the comparison that feeds
VEC_COND_EXPR. I'm going to prepare a patch..
