https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126771
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Hongtao Liu from comment #4) > (In reply to Richard Biener from comment #3) > > Oh, this is also a x86 target issue as we miss vcond_mask_v2siqi for > > MMX-with-SSE. We have vcond_mask_v2siv2si and vcond_mask_v2diqi but I'll > > note the > > vectorizer isn't able to switch between AVX512 and SSE style masking at > > will. > > We also miss vec_cmpv2sfqi, in practice this degrades MMX-with-SSE > > vectorization > > once AVX512VL is enabled. > > > > > ix86_get_mask_mode always return vector mask for v2sf/v2si mask, so i > thought vcond_mask_v2sfqi/vec_cmpv2sfqi are not needed. Yes, but it causes the extra vpmovqd %xmm0, %xmm0, using a QI mode mask would have helped this case. > There could be mixed mask for different vector size/type from > ix86_get_mask_mode, .i.e Under avx512vl + avx512bw, v4si get kmask, but > vector mask for v2si, would that be a problem for the vectorizer? We currently lack mask mode interaction, so if we'd have to unpack a 4 bit mask to a two bit mask then both have to be either integer modes or vector modes. But I'd expect this would be corner cases only. What I wanted to say is that the choice of integer or vector mask is hard-wired via the target hook so the vectorizer cannot chose freely. In particular during pattern recognition we do not really know whether we're dealing with V4SI or V2SI vectors, so if the mask mode kind differs (that is, the ISA is non-uniform), this might lead to missed optimizations. In this case the V2DF compare produces a QImode mask but the vcond_mask wants to produce a V2SI result which requires a V2SImode mask, so we have to go through vcond_mask_v2diqi and then v2di to v2si conversion.
