<a...@codesourcery.com> writes: > This feature probably ought to be reworked as a proper target hook, but I > would > like to know if this is the correct solution to the problem first. > > The problem is that GCN vectors have a fixed number of elements (64) and the > vector size varies with element size. E.g. V64QI is 64 bytes and V64SI is 256 > bytes. > > This is a problem because GCC has an assumption that a) vector registers are > fixed size, and b) if there are multiple vector sizes you want to pick one > size > and stick with it for the whole function.
The whole of the current vectorisation region rather than the whole function, but yeah, this is a fundamental assumption with the current autovec code. It's something that would be really good to fix... > This is a problem in various places, but mostly it's not fatal. However, > get_vectype_for_scalar_type caches the vector size for the first type it > encounters and then tries to apply that to all subsequent vectors, which > completely destroys vectorization. The caching feature appears to be an > attempt to cope with AVX having a different vector size to other x86 vector > options. > > This patch simply disables the cache so that it must ask the backend for the > preferred mode for every type. TBH I'm surprised this works. Obviously it does, otherwise you wouldn't have posted it, but it seems like an accident. Various parts of the vectoriser query current_vector_size and expect it to be stable for the current choice of vector size. The underlying problem also affects (at least) base AArch64, SVE and x86_64. We try to choose vector types on the fly based only on the type of a given scalar value, but in reality, the type we want for a 32-bit element (say) often depends on whether the vectorisation region also has smaller or larger elements. And in general we only know that after vect_mark_stmts_to_be_vectorized, but we want to know the vector types earlier, such as in pattern recognition and while building SLP trees. It's a bit of a chicken-and-egg problem... Richard
