On Tue, 29 Jan 2013, Richard Biener wrote:
On Sun, Jan 27, 2013 at 4:28 PM, Marc Glisse <marc.gli...@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,
--
Marc Glisse
