> > > When predicating a load we implicitly assume that the else value is > > > zero. In order to formalize this this patch queries the target for > > > its supported else operand and uses that for the maskload call. > > > Subsequently, if the else operand is nonzero, a cond_expr enforcing > > > a zero else value is emitted. > > Why? I don't think the vectorizer relies on a particular else > value? I'd say it would be appropriate for if-conversion to > use "ANY" and for the vectorizer to then pick a supported > version and/or enforce the else value it needs via a blend?
In PR115336 we have something like _Bool iftmp.0_113; _Bool iftmp.0_114; iftmp.0_113 = .MASK_LOAD (_170, 8B, _169, _171(D)); iftmp.0_114 = _47 | iftmp.0_113; which assumes zeroing. In order to circumvent that we could use COND_IOR but I suppose that wouldn't be optimized away even on targets that zero masked elements? "ANY" would seem to be wrong here. So instead, right now the flow is to emit a COND_EXPR after the MASK_LOAD here if the target does not zero and have the vectorizer vectorize it into a blend (or something else if the surrounding code allows). What I didn't do (in the posted version, just locally) is an explicit VEC_COND_EXPR after each masked (gather/load lanes) call the vectorizer does. Do we need that? AFAICT loop masking (be it len style or fully-masked style) should be safe. -- Regards Robin
