Comments

Hello,
this message is to check that I am not doing something absurd and ask for
a bit of advice.
In the attached patch, I let SLP recognize vector loads/stores just like
it 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
strip the bit_field_ref, but since the base address is right and the base
object is almost unused...), but most importantly it only works if the
vectors have their address taken, otherwise (after asking gimple_vuse?)
SLP doesn't detect their use as loads or stores at all. Also, it only
works if you write result[0]=..., result[1]=... and does not recognize a
constructor as a series of stores.
Is slowly extending SLP the right way to go? Should get_references_in_stmt
report vector element accesses?
(the patch as is passes the testsuite on x86_64-linux and vectorizes the
few examples I tried)

On Tue, 29 Jan 2013, Richard Biener wrote:
> On Sun, Jan 27, 2013 at 4:28 PM, Marc Glisse <marc.glisse@inria.fr> wrote:>> Hello,>>>> this message is to check that I am not doing something absurd and ask for a>> bit of advice.>>>> In the attached patch, I let SLP recognize vector loads/stores just like it>> 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 strip>> the bit_field_ref, but since the base address is right and the base object>> is almost unused...), but most importantly it only works if the vectors have>> 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[0]=..., result[1]=... and does not recognize a constructor as a>> series of stores.>>>> Is slowly extending SLP the right way to go? Should get_references_in_stmt>> 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[0] = v[0] + v[0];> w[1] = v[1] + v[1];>> into>> w = v + v;>> As it would work if w and v are array accesses instead of vector subscripts?
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 accesses.
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.
> 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.
> They should be split out> and separately tested anyway. The data-ref part at least will confuse> analysis of 'a[0]' or 'a[1]' vs. 'a', but I suppose independent of the patch.
Ah... Could you be more specific? Are you thinking about arrays of
vectors?
Thanks for the help,

On Wed, Jan 30, 2013 at 9:45 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Tue, 29 Jan 2013, Richard Biener wrote:>>> On Sun, Jan 27, 2013 at 4:28 PM, Marc Glisse <marc.glisse@inria.fr> wrote:>>>>>> Hello,>>>>>> this message is to check that I am not doing something absurd and ask for>>> a>>> bit of advice.>>>>>> In the attached patch, I let SLP recognize vector loads/stores just like>>> it>>> 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>>> strip>>> the bit_field_ref, but since the base address is right and the base>>> object>>> is almost unused...), but most importantly it only works if the vectors>>> have>>> 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[0]=..., result[1]=... and does not recognize a constructor as a>>> series of stores.>>>>>> Is slowly extending SLP the right way to go? Should>>> get_references_in_stmt>>> 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[0] = v[0] + v[0];>> w[1] = v[1] + v[1];>>>> into>>>> w = v + v;>>>> As it would work if w and v are array accesses instead of vector>> subscripts?>>> 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>> accesses.>>> 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[0]' or 'a[1]' vs. 'a', but I suppose independent of the>> patch.>>> 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.
Richard.
> Thanks for the help,>> --> Marc Glisse