SLP for vectors
Thu Jan 31 09:14:00 GMT 2013
On Wed, Jan 30, 2013 at 9:45 PM, Marc Glisse <firstname.lastname@example.org> wrote:
> On Tue, 29 Jan 2013, Richard Biener wrote:
>> On Sun, Jan 27, 2013 at 4:28 PM, Marc Glisse <email@example.com> wrote:
>>> this message is to check that I am not doing something absurd and ask for
>>> bit of advice.
>>> In the attached patch, I let SLP recognize vector loads/stores just like
>>> recognizes those in an array. It has a few issues: the cost of the
>>> vectorized version is overestimated, the base object is wrong (doesn't
>>> the bit_field_ref, but since the base address is right and the base
>>> is almost unused...), but most importantly it only works if the vectors
>>> their address taken, otherwise (after asking gimple_vuse?) SLP doesn't
>>> detect their use as loads or stores at all.
>> Yes, if they have not their address taken they are not loads.
>>> Also, it only works if you write
>>> result=..., result=... and does not recognize a constructor as a
>>> series of stores.
>>> Is slowly extending SLP the right way to go? Should
>>> report vector element accesses?
>> It does if it is a memory access.
>> You didn't provide a new testcase so it's hard for me to guess what you
>> are trying to do. I suppose you want to vectorize
>> w = v + v;
>> w = v + v;
>> w = v + v;
>> As it would work if w and v are array accesses instead of vector
> Yes, sorry for not being more precise. Vectorization that works for an array
> should work (even better) for a vector.
>> Note that similar issues (and bugreports) exist for complex component
> One extension at a time :-)
>> As of handling non-memory BIT_FIELD_REFs - I suggest to split out
>> the test of whether a stmt is considered a "load" for the purpose of
>> vectorization and simply special-case this therein, not requiring a VUSE.
> Ok. The hardest part will be preventing the pass from creating ADDR_EXPR of
> those vectors, or at least folding them before the pass is done.
Oh ... I suppose the "loads"/"stores" need simply be specially handled.
>> I suppose the data-ref analysis parts are not strictly required, nor
>> the get_addr_base_and_unit_offset_1 parts?
> Actually it is necessary (at least the get_addr_base_and_unit_offset_1 part
> is) otherwise I get a gimple verification failure because we have an
> ADDR_EXPR of a BIT_FIELD_REF.
Hm. Certainly handling BIT_FIELD_REF in get_addr_base_and_unit_offset_1
is ok, but we should ensure by other means that the address of a
BIT_FIELD_REF is never taken ...
>> They should be split out
>> and separately tested anyway. The data-ref part at least will confuse
>> analysis of 'a' or 'a' vs. 'a', but I suppose independent of the
> Ah... Could you be more specific? Are you thinking about arrays of vectors?
No, I was thinking of code that accesses both the whole vector and the
vector piecewise. Mixing this kind of accesses will confuse data-ref
analysis I believe. But it also will disable vectorization because there are
already vector types in the IL ... so it's probably a minor issue for now.
> Thanks for the help,
> Marc Glisse
More information about the Gcc-patches