Jakub Jelinek <ja...@redhat.com> writes: > On Wed, Jun 24, 2020 at 09:35:42AM +0100, Richard Sandiford wrote: >> >> I keep meaning to experiment with dropping the second mode from these >> >> optabs, >> >> since it should be uniquely determined by the first. That would make >> >> things >> >> slightly simpler and more consistent with the other load/store IFNs. But >> >> as >> >> usual I've never found the time. >> > >> > AVX512 would have V16SImode and SImode because the mask would have >> > an integer mode? Likewise I could imagine RISC-V using V4SImode and >> > V4QImode >> > or however their mask registers look like. >> >> But what I mean is, once you know the vector mode, there should only >> be one “choice” of mask mode. (I agree it might not be the same mode, >> and isn't for SVE as well as AVX512.) TARGET_GET_MASK_MODE and related >> vectoriser masking code is based around the assumption that the mask >> mode is a function of the vector mode. > > But on the same target the same vector mode (e.g. V16HImode) can have two > different mask modes (for AVX and non-AVX512VL V16HImode, for AVX512VL > HImode). It is true that better both shouldn't appear in the same function, > but it would be better if at least in the optabs it is clearly spelled out.
Hmm, OK. The reason for bringing this up is that we took the above shortcut for things like mask_gather_load_optab. That's a convert optab in which one mode is the data vector mode and the other is the index vector mode (which can vary independently of the data mode to some extent). If we allow multiple mask modes for the same pair of index and data vector modes, we'd presumably need to add support for three-mode optabs. I don't know whether that would be a practical problem for AVX or not, if it did switch to using ifns instead of built-in functions for autovectorised gathers. Richard
