https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 26 Jun 2020, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830 > > --- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> --- > Thanks for reduction, I can confirm that. What happens: > > mips-ps-5.c.171t.loopdone: > > _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>; > > which is fine. But then during veclower21 we lower the first comparison to: > > _24 = (void *) ivtmp.17_4; > vect__1.7_28 = MEM[base: _24, offset: 0B]; > _23 = (void *) ivtmp.20_1; > vect__2.10_31 = MEM[base: _23, offset: 0B]; > vect__3.11_33 = vect__2.10_31 + vect_cst__32; > _26 = BIT_FIELD_REF <vect__1.7_28, 32, 0>; > _27 = BIT_FIELD_REF <vect__3.11_33, 32, 0>; > _29 = _26 == _27 ? -1 : 0; > _30 = BIT_FIELD_REF <vect__1.7_28, 32, 32>; > _36 = BIT_FIELD_REF <vect__3.11_33, 32, 32>; > _37 = _30 == _36 ? -1 : 0; > _34 = {_29, _37}; > vect_iftmp.12_35 = VEC_COND_EXPR <_34, vect__1.7_28, vect__2.10_31>; > > which is undesired. So similarly to isel we need to mark all SSA_NAMEs that > are > first args of a VEC_COND_EXPR and ignore these from vect lowering. > Richi? 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)? 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?
