On Thu, Sep 6, 2012 at 1:06 AM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Wed, 5 Sep 2012, Gabriel Dos Reis wrote: > >> On Wed, Sep 5, 2012 at 5:09 PM, Iyer, Balaji V <balaji.v.i...@intel.com> >> wrote: >>> >>> Let's say we have two for loops like this: >>> >>> int my_func (int x, int y); >>> >>> For (ii = 0; ii < 10000; ii++) >>> X[ii] = my_func (Y[ii], Z[ii]); > > > I assume X, Y and Z are __restrict pointers (or something the compiler can > detect doesn't alias).
I assumed this much. > > >> 2. Considering this example, won't you get the same behaviour >> if my_func was declared with "pure" attribute? If not, why? > > > AFAIU, my_func is defined in a separate library and because of the attribute > on the definition, it will actually export overloads: > int myfunc(int,int); > v2si myfunc(v2si,v2si); > v4si myfunc(v4si,v4si); > etc (where does it stop? seems problematic if the library is compiled for > sse4 and I then compile and link an avx program) Thanks but I was not talking of anything this complicated. The "pure" attribute has nothing to do with overloading? > > (hopefully with implementations more clever than breaking the vectors into > pieces and calling the basic myfunc on each) > > The attribute on the declaration then lets gcc's vectorizer know it can call > those overloads. My question was why the same conclusion won't be reached on the example given if the function was declared with the "pure attribute. > > With suitable pure/const attribute you could unroll the loop a bit and > reorder the calls to myfunc, but without myfunc's body, you couldn't do as > much. > > Note that this is my guess from reading the example and completely ignoring > the patch, it could be miles from the truth, and it needs better explanation > (the doc patch is coming later in the series IIRC). Note that the example given, was a function taking two ints and returning an int. How would a function with "pure" attribute fool the vectorizer? -- Gaby
