GCC sometimes loses alignment information. If we declare an aligned pointer type: // These two lines work (together) typedef real aligned_real __attribute__((aligned(16))); typedef const aligned_real* SSE_PTR; Then gcc generates aligned access here: // This function uses ALIGNED accesses real f(SSE_PTR p, SSE_PTR q,int n) { real sum = 0; for(int i=0; i<n;i++) sum += p[i] * q[i]; return sum; } But not here: real f2a(const double* p_, const double* q_,int n) { SSE_PTR __restrict__ p = p_; SSE_PTR __restrict__ q = q_; real sum = 0; for(int i=0; i<n;i++) sum += p[i] * q[i]; return sum; } This could matter when the user know which things are aligned. gcc version 4.5.0 20100119 (experimental) [trunk revision 156049] (Ubuntu 20100119-0ubuntu1) gcc-4.5 -g -c test.C -O3 -ffast-math -msse3 -mtune=barcelona -ftree-vectorizer-verbose=4
Created attachment 19693 [details] Several simple examples for alignment in vectorization. The notes in the file about which functions contain aligned accesses were accurate around Dec 31, 2009. However, they have changed, and fewer things are aligned on Jan 22, 2010.
Yep. I always fail to see why the vectorizer doesn't use the alignment information present in from data-ref analysis: t.i:9: note: === vect_analyze_data_refs === Creating dr for *D.2752_12 ... (res = {p_4, +, 4}_1)) base_address: p__3(D) offset from base address: 0 constant offset from base address: 0 step: 4 aligned to: 128 base_object: *(const aligned_real * restrict) p__3(D) thus the base is aligned to 128 bits, offset and constant offset are constant zero so the vectorizer should be able to compute alignment of all accesses. Still it says t.i:9: note: === vect_analyze_data_refs_alignment === t.i:9: note: vect_compute_data_ref_alignment: t.i:9: note: can't force alignment of ref: *D.2752_12 t.i:9: note: vect_compute_data_ref_alignment: t.i:9: note: can't force alignment of ref: *D.2754_16 ... t.i:9: note: Vectorizing an unaligned access. t.i:9: note: Vectorizing an unaligned access.
This has already been discussed in PR 41464. Ira
*** This bug has been marked as a duplicate of 41464 ***