>> Also, I believe the implementation right now implicitly requires a zero >> else value, at least for the mask-inactive elements. For elements past >> the length the else can be undefined as every consumer of the comparison >> result will be length masked again. Ignoring the len/tail, I still >> think cond_vec_cmp/cond_len... needs an else value. I would not do all >> the discovery and workarounds that we have for masked load's else >> operands but instead just force it to zero and have targets deal with >> it, so no extra work for SVE just for RVV. > > Is this true though. > > X = COND_LEN_VEC_CMP (...) > if (x != 0) > ... > > The consumer isn't LEN masked, at least in GIMPLE. So having a non-zero > else value makes this undefined.
It depends on what (X != 0) actually does. I'd argue that (X != 0) should be implicitly controlled (at least for the RVV approach). And if we define it as masked "reduction"/COND_LEN_COUNT_ACTIVE, the compare could be unmasked. I guess that's again the question of what to mask, the producer or the consumer. Of course we need to pay attention to not emit this when there are "unsafe" consumers (and we only have control over this in the vectorizer, not in later, local passes). I think I agree that if we go for the "producer masks" approach, there's no other way than enforcing a zero else value, as it relies on local passes to fix up things. I just hope that we never need this particular IFN for RVV ;) In the latter case I wouldn't have a problem with just keeping "must zero inactive lanes" in the docs for those IFNs that are non RVV-"specific". Then an explicit else value is of course unnecessary. -- Regards Robin
