[gomp4] Some progress on #pragma omp simd

On Sat, Apr 27, 2013 at 08:17:35PM +0200, Jakub Jelinek wrote:
> One way we could implement the SIMD private/lastprivate/reduction
> vars and for Cilk+ also firstprivate ones might be:
> - query the target what the maximum possible vectorization factor for the
>   loop is (and min that with simdlen if any), let's call it MAXVF
...

I've made some progress on this, but am still far from being there, so
looking for comments.  Known unhandled things are that the inliner doesn't
remap the simd uids (neither in loop structure nor in
__builtin_GOMP.simd_{vf,lane} arguments), the 
adjust_simduid_builtins subpass doesn't actually try to shrink the sizes
of the arrays back to the decided vectorization factor, LTO doesn't handle
simd uids, and most importantly that the vectorizer still does a poor job on
it.  Also, not sure what to do for lastprivate, probably use the magic
arrays and just in the epilogue of the loop compute which of the array items
belonged to the last iteration somehow.

I was using:
int a, b[1024];
struct S { S (); ~S (); int s; };

#pragma omp declare simd
__attribute__((noinline, noclone)) void
bar (int &x, int &y)
{
  x += 4;
  y += 4;
}

int
foo (void)
{
  int i, j = 0, x;
  S s;
  #pragma omp simd private(x) private(s) reduction(+:j)
  for (i = 0; i < 1024; i++)
    {
      a = 6;
      x = 8;
      s.s += 1;
      b[i] += a + x + s.s;
      j += b[i];
    }
  return j;
}
as a testcase, x being non-addressable scalar is just handled
normally, it shouldn't be observable if we have just one copy or more.
s, being addressable class that also needs to be constructed/destructed is
using the magic arrays and so is reduction.  While the vectorizer can
recognize some reductions, e.g. without -ffast-math it will not vectorize
any floating point ones because that means changing the order of
computations, while when they are mandated to be one copy per simd lane,
the order of computations is clear and thus can be vectorized.
Also, especially with user defined reductions the reduction can be a
function call etc.

So, what I get out of ompexp on this is an initializing loop like:
  <bb 3>:
  D.2719 = __builtin_GOMP.simd_vf (1);
  D.2713 = 0;
  goto <bb 5>;

  <bb 4>:
  D.2715[D.2713] = 0;
  D.2718 = &D.2717[D.2713];
  S::S (D.2718);
  D.2713 = D.2713 + 1;

  <bb 5>:
  if (D.2713 < D.2719)
    goto <bb 4>;
  else
    goto <bb 6>;
then the main loop:
  <bb 6>:
  i = 0;
  goto <bb 8>;

  <bb 7>:
  D.2714 = __builtin_GOMP.simd_lane (1);
  a = 6;
  x = 8;
  D.2701 = D.2717[D.2714].s;
  D.2702 = D.2701 + 1;
  D.2717[D.2714].s = D.2702;
  D.2703 = b[i];
  a.0 = a;
  D.2705 = a.0 + x;
  D.2701 = D.2717[D.2714].s;
  D.2706 = D.2705 + D.2701;
  D.2707 = D.2703 + D.2706;
  b[i] = D.2707;
  D.2703 = b[i];
  D.2727 = D.2715[D.2714];
  D.2728 = D.2703 + D.2727;
  D.2715[D.2714] = D.2728;
  i = i + 1;

  <bb 8>:
  if (i < 1024)
    goto <bb 7>;
  else
    goto <bb 9>;
and lastly a destruction/reduction loop:
  <bb 9>:
  D.2723 = __builtin_GOMP.simd_vf (1);
  D.2713 = 0;
  goto <bb 11>;

  <bb 10>:
  D.2716 = D.2715[D.2713];
  j = j + D.2716;
  D.2718 = &D.2717[D.2713];
  S::~S (D.2718);
  D.2713 = D.2713 + 1;

  <bb 11>:
  if (D.2713 < D.2723)
    goto <bb 10>;
  else
    goto <bb 12>;

I've discussed with richi on IRC the vectorizer data ref stuff somewhat,
but in the end kept this special function simd_lane, as the array indexes
modulo vectorization factor are nothing close to what the vectorizer was able
to handle.  What I get in *.optimized is:
  <bb 5>:

  <bb 6>:
  # ivtmp.41_45 = PHI <ivtmp.41_32(5), ivtmp.41_64(11)>
  vect__17.10_7 = MEM[(struct S[32] *)&D.2717];
  vect__18.11_1 = vect__17.10_7 + { 1, 1, 1, 1, 1, 1, 1, 1 };
  MEM[(struct S[32] *)&D.2717] = vect__18.11_1;
  _65 = (void *) ivtmp.41_45;
  vect__20.17_50 = MEM[base: _65, offset: 0B];
  vect__21.18_52 = vect__17.10_7 + { 15, 15, 15, 15, 15, 15, 15, 15 };
  vect__22.20_53 = vect__20.17_50 + vect__21.18_52;
  MEM[base: _65, offset: 0B] = vect__22.20_53;
  vect__24.25_58 = MEM[(int[32] *)&D.2715];
  vect__25.26_59 = vect__22.20_53 + vect__24.25_58;
  MEM[(int[32] *)&D.2715] = vect__25.26_59;
  ivtmp.41_32 = ivtmp.41_45 + 32;
  if (ivtmp.41_32 != _20)
    goto <bb 5>;
  else
    goto <bb 7>;
though, there is no pass that would be able to turn the memory accesses
into a vector load before the loop and just operations on vector register
followed by vector store at the end of the loop, and while CSE is able to
improve it somewhat at the RTL level, I still end up with unnecessary stack
stores inside of the loop.
        vmovdqa 160(%rsp), %ymm0
        movl    $b, %eax
        vmovdqa .LC0(%rip), %ymm3
        vmovdqa .LC1(%rip), %ymm2
.L8:
        vmovdqa %ymm0, %ymm1
        addq    $32, %rax
        vpaddd  %ymm3, %ymm0, %ymm0
        vmovdqa %ymm0, 160(%rsp)	! This is not needed
        vpaddd  %ymm2, %ymm1, %ymm1
        vpaddd  -32(%rax), %ymm1, %ymm1
        vmovdqa %ymm1, -32(%rax)
        cmpq    $b+4096, %rax
        vpaddd  32(%rsp), %ymm1, %ymm1	! 32(%rsp) could be read before loop
        vmovdqa %ymm1, 32(%rsp)		! This is not needed
        jne     .L8
! and we could just store %ymm0 to 160(%rsp) here
and %ymm4 to 32(%rsp).

Thoughts?

	Jakub

[gomp4] Some progress on #pragma omp simd

Commit Message

Comments

Patch