Bug 713586

So far I've looked just at ptr_c_gr.  Here is a self-contained testcase for that:
typedef double __attribute__ ((aligned (16))) D;
__attribute__((noinline, noclone))
void foo (D *out1, D *out2, D *out3, D *in1, D *in2, int len)
{
  for (int i = 0; i < len; ++i)
    {
      out1[i] = in1[i] * in2[i];
      out2[i] = in1[i] + in2[i];
      out3[i] = in1[i] - in2[i];
    }
}
#ifndef N
#define D 1
#define N 16
#endif
typedef union { int i __attribute__((aligned (N))); double d[0]; } U;
__attribute__((noinline, noclone))
void bar (U *out1, U *out2, U *out3, U *in1, U *in2, int len)
{
  for (int i = 0; i < len; ++i)
    {
      out1->d[i] = in1->d[i] * in2->d[i];
      out2->d[i] = in1->d[i] + in2->d[i];
      out3->d[i] = in1->d[i] - in2->d[i];
    }
}
double a[50000] __attribute__((aligned (32)));
int
main ()
{
  int i;
  for (i = 0; i < 500000; i++)
#ifdef D
    foo (a + 0, a + 10000, a + 20000, a + 30000, a + 40000, 10000);
#else
    bar ((U *) (a + 0), (U *) (a + 10000), (U *) (a + 20000),
         (U *) (a + 30000), (U *) (a + 40000), 10000);
#endif
  return 0;
}

for i in "" "-DN=16" "-DN=32"; do \
  for j in "/usr/src/gcc-4.4-rh/obj/gcc/cc1plus -w -quiet" \
           "g++ -S" "g++ -S -mavx"; do \
    echo "$i" "$j"; eval $j -O3 -mtune=generic $i foo.c -o foo.s; \
    g++ -o foo foo.s; ./foo; ( time ./foo ) 2>&1 | grep user; \
  done; \
done
 /usr/src/gcc-4.4-rh/obj/gcc/cc1plus -w -quiet
user	0m6.369s
 g++ -S
user	0m7.803s
 g++ -S -mavx
user	0m7.648s
-DN=16 /usr/src/gcc-4.4-rh/obj/gcc/cc1plus -w -quiet
user	0m6.310s
-DN=16 g++ -S
user	0m6.489s
-DN=16 g++ -S -mavx
user	0m5.442s
-DN=32 /usr/src/gcc-4.4-rh/obj/gcc/cc1plus -w -quiet
user	0m6.325s
-DN=32 g++ -S
user	0m6.156s
-DN=32 g++ -S -mavx
user	0m5.506s

In the case where N isn't defined, i.e. the original ptr_c_gr, I think the main difference is that g++ 4.4 used to vectorize it, but 4.6 doesn't.
It stopped being vectorized at:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157088
aka http://gcc.gnu.org/PR43188
The question is if this is a way we want to support as a way to say the arguments are aligned.  The testcase contains a different way of saying the same, which apparently works.  Talked about this on IRC and the result of the
discussion was that the best thing would be add a new attribute, ptr_align,
where __attribute__((ptr_align (16))) would mean the parameter is 16 byte aligned.  Or it could be represented as if ((uintptr_t) out1) & 15) __builtin_unreachable (); - kind of assert alternative that would generate no code.

When the loop is vectorized with both old and new compiler, not sure if the differences aren't just measurement errors.  I've run it again with 2000000
instead of 500000 iterations and got:
 /usr/src/gcc-4.4-rh/obj/gcc/cc1plus -w -quiet
user	0m25.277s
 g++ -S
user	0m31.888s
 g++ -S -mavx
user	0m30.448s
-DN=16 /usr/src/gcc-4.4-rh/obj/gcc/cc1plus -w -quiet
user	0m25.444s
-DN=16 g++ -S
user	0m25.388s
-DN=16 g++ -S -mavx
user	0m21.580s
-DN=32 /usr/src/gcc-4.4-rh/obj/gcc/cc1plus -w -quiet
user	0m25.307s
-DN=32 g++ -S
user	0m25.461s
-DN=32 g++ -S -mavx
user	0m22.778s

The following is vectorized in both cases, but seems to be reproduceably slower with 4.6:
__attribute__((noinline, noclone))
void baz (double *out1, double *out2, double *out3, double *in1, double *in2, int len)
{
  for (int i = 0; i < len; ++i)
    {
      out1[i] = in1[i] * in2[i];
      out2[i] = in1[i] + in2[i];
      out3[i] = in1[i] - in2[i];
    }
}

double a[50000] __attribute__((aligned (32)));
int
main ()
{
  int i;
  for (i = 0; i < 500000; i++)
    baz (a + 0, a + 10000, a + 20000, a + 30000, a + 40000, 10000);
  return 0;
}

4.4:
Strip out best and worst realtime result
minimum: 6.645898640 sec real / 0.000062341 sec CPU
maximum: 6.921587077 sec real / 0.000157156 sec CPU
average: 6.746931725 sec real / 0.000134046 sec CPU
stdev  : 0.076195043 sec real / 0.000021599 sec CPU

4.6:
Strip out best and worst realtime result
minimum: 6.947258042 sec real / 0.000073529 sec CPU
maximum: 7.463546534 sec real / 0.000160966 sec CPU
average: 7.225394743 sec real / 0.000138264 sec CPU
stdev  : 0.113974332 sec real / 0.000015305 sec CPU

On the #c2 testcase the slowdown seems to be caused by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148211
i.e. misaligned store support in the vectorizer:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00492.html
The patch talks about need to add a cost model, not sure if it has been added for this.

__builtin_assume_aligned is now backported to 4.6-RH in gcc-4.6.1-2.fc{15,16} as well as gcc46-4.6.1-2.el{5,6}.

For GCC 4.4-RH __builtin_assume_aligned isn't really backportable though, it heavily relies on bit tracking in CCP, which has been only introduced in GCC 4.6.

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.