I entirely agree. There definitely should be a PR for this, if there isn't already.
dorit "Michael James" <[EMAIL PROTECTED]> wrote on 05/11/2006 22:03:47: > Hello Dorit, > > Thank you for the list of references. > > What I gathered from reading this is that alignment attributes applied > to the base element of an array are causing problems for other > legitimate uses of this attribute. It is basically stupid to specify > the base type of an array be aligned because this implies that the > array elements are scattered in memory. The only examples I can think > of where you might want to do that is with multidimensional arrays > where you want the start of each subarray to be aligned. That is > better solved just by changing the length of the inner array to one > that yields the desired alignment. > > However, specifying pointer alignment (whether this hint is passed > through the type system or some other way) is an important piece of > information that a programmer may wish to communicate to the > optimizer. The obvious semantics for the hint are that the > log2(alignment) least significant bits of the pointer value are clear. > The size of the pointer base type would be unaffected so that pointer > math can still yield unaligned access. > > I hope I have not oversimplified the issue at hand here. From the > point of view of someone passively benefiting from the optimizer, this > issue does not matter so much. However, someone who is performance > tuning his code may care very much about getting this information > through to the vectorizor and without some provision for a hint he is > stuck either (1) without the optimization or (2) rewriting the code so > that all aligned arrays are passed as pointer-to-struct with the array > element in the struct specified with an alignment attribute. I have > not tested method 2; it seems like a transformation which may work > despite being unaesthetic. > > Regards, > Michael James > > On 11/5/06, Dorit Nuzman <[EMAIL PROTECTED]> wrote: > > Unfortunately there's no way to specify alignment attribute of pointers in > > GCC - the syntax was allowed in the past but not really supported > > correctly, and then entirely disallowed (by this patch > > http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02284.html). This issue was > > discussed in details in these threads: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794 > > http://gcc.gnu.org/ml/gcc/2005-03/msg00483.html > > (and recently came up again also in > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827#c56). > > The problem is that > > "We don't yet implement either attributes on array parameters applying to > > the array not the pointer, or attributes inside the [] of the array > > parameter applying to the pointer. (This is documented in "Attribute > > Syntax".)" (from the above thread). > > > > dorit > > > > > > > Hello, > > > > > > I have been playing with gcc's new (to me) auto vectorization > > > optimizations. I have a particular loop for which I have made external > > > provisions to ensure that the data is 16-byte aligned. I have tried > > > everything I can think of to give gcc the hint that it is operating on > > > aligned data, but still the vectorizer warns that it is operating on > > > unaligned data and generates the less efficient MOVLPS/MOVUPS instead > > > of MOVAPS. > > > > > > The code is like this: > > > > > > #define SSE __attribute__((aligned (16))) > > > > > > typedef float matrix_t[100][1024]; > > > > > > matrix_t aa SSE, bb SSE, cc SSE; > > > > > > void calc(float *a, float *b, float *c) { > > > int i, n = 1024; > > > > > > for (i=0; i<n; ++i) { > > > a[i] = b[i] / (b[i] + c[i]); > > > } > > > > > > } > > > > > > int main(void) { > > > int i, n = 100; > > > for (i=0; i<n; ++i) { > > > calc(a[i], b[i], c[i]); > > > } > > > } > > > > > > gcc rejects if I specify alignment attributes on the formal parameters > > > (obviously it was dumb to even try that), and there does not seem to > > > be a way to get the alignment hint to apply to the object referenced > > > by the pointer instead of the pointer itself. > > > > > > In my application it is important that the function doing the > > > computations remains abstracted away from the data definitions, as > > > there is over 1G of data dynamically arranged and the actual alignment > > > provisions are made with mmap(). > > > > > > Does anyone have a suggestion? > > > > > > Regards, > > > Michael James > > > >
