"H.J. Lu" <hjl.to...@gmail.com> writes: > 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.
Yeah, we're hit by this for AArch64 too. Andre's recent patches: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01564.html https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00205.html should help. > Can vectorizer > support 2 sets of vector sizes, one for known trip count and the other > for unknown > trip count? The approach Andre's taking is to continue to use the wider vector size for unknown trip counts, and instead ensure that the epilogue loop is vectorised at the narrower vector size if possible. The patches then use this vectorised epilogue as a fallback "main" loop if the runtime trip count is too low for the wide vectors. Thanks, Richard
