On Wed, Jan 30, 2013 at 9:45 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > 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.
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