On 17/09/18 20:28, Richard Sandiford wrote:
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.
Indeed, this is why this remains only a half-baked patch: I wasn't
confident it was the correct or whole solution.
It works in so much as it fixes the immediate problem that I saw -- "no
vector type" -- and makes a bunch of vect.exp testcases happy.
It's quite possible that something else is unhappy with this.
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...
I don't understand why the number of bits in a vector is the key
information here?
It would make sense if you were to say that the number of elements has
to be fixed in a given region, because obviously that's tied to loop
strides and such, but why the size?
It seems like there is an architecture were you don't want to mix
instruction types (SSE vs. AVX?) and that makes sense for that
architecture, but if that's the case then we need to be able to turn it
off for other architectures.
For GCN, vectors are fully maskable, so we almost want such
considerations to be completely ignored. We basically want it to act
like it can have any size vector it likes, up to 64 elements.
Andrew
