On Wed, Oct 23, 2019 at 4:51 AM Richard Sandiford <richard.sandif...@arm.com> wrote: > > Richard Biener <richard.guent...@gmail.com> writes: > > On Wed, Oct 23, 2019 at 1:00 PM Richard Sandiford > > <richard.sandif...@arm.com> wrote: > >> > >> This patch is the first of a series that tries to remove two > >> assumptions: > >> > >> (1) that all vectors involved in vectorisation must be the same size > >> > >> (2) that there is only one vector mode for a given element mode and > >> number of elements > >> > >> Relaxing (1) helps with targets that support multiple vector sizes or > >> that require the number of elements to stay the same. E.g. if we're > >> vectorising code that operates on narrow and wide elements, and the > >> narrow elements use 64-bit vectors, then on AArch64 it would normally > >> be better to use 128-bit vectors rather than pairs of 64-bit vectors > >> for the wide elements. > >> > >> Relaxing (2) makes it possible for -msve-vector-bits=128 to preoduce > >> fixed-length code for SVE. It also allows unpacked/half-size SVE > >> vectors to work with -msve-vector-bits=256. > >> > >> The patch adds a new hook that targets can use to control how we > >> move from one vector mode to another. The hook takes a starting vector > >> mode, a new element mode, and (optionally) a new number of elements. > >> The flexibility needed for (1) comes in when the number of elements > >> isn't specified. > >> > >> All callers in this patch specify the number of elements, but a later > >> vectoriser patch doesn't. I won't be posting the vectoriser patch > >> for a few days, hence the RFC/A tag. > >> > >> Tested individually on aarch64-linux-gnu and as a series on > >> x86_64-linux-gnu. OK to install? Or if not yet, does the idea > >> look OK? > > > > In isolation the idea looks good but maybe a bit limited? I see > > how it works for the same-size case but if you consider x86 > > where we have SSE, AVX256 and AVX512 what would it return > > for related_vector_mode (V4SImode, SImode, 0)? Or is this > > kind of query not intended (where the component modes match > > but nunits is zero)? > > In that case we'd normally get V4SImode back. It's an allowed > combination, but not very useful. > > > How do you get from SVE fixed 128bit to NEON fixed 128bit then? Or is > > it just used to stay in the same register set for different component > > modes? > > Yeah, the idea is to use the original vector mode as essentially > a base architecture. > > The follow-on patches replace vec_info::vector_size with > vec_info::vector_mode and targetm.vectorize.autovectorize_vector_sizes > with targetm.vectorize.autovectorize_vector_modes. These are the > starting modes that would be passed to the hook in the nunits==0 case. >
For a target with different vector sizes, targetm.vectorize.autovectorize_vector_sizes doesn't return the optimal vector sizes for known trip count and unknown trip count. For a target with 128-bit and 256-bit vectors, 256-bit followed by 128-bit works well for known trip count since vectorizer knows the maximum usable vector size. But for unknown trip count, we may want to use 128-bit vector when 256-bit code path won't be used at run-time, but 128-bit vector will. At the moment, we can only use one set of vector sizes for both known trip count and unknown trip count. Can vectorizer support 2 sets of vector sizes, one for known trip count and the other for unknown trip count? H.J.
