[gomp4] Some progress on #pragma omp simd

On Tue, Jun 18, 2013 at 02:15:55PM -0500, Aldy Hernandez wrote:
> >Please move simduid after force_vect, so that it is better packed.
> 
> Fixed.
> 
> I also rewrote the builtins to use the internal function doo-dah as
> previously suggested.
> 
> Let me know if this is fine with y'all and you (Jakub) can keep this
> patch and apply it on top of your pending patchset for clauses.

Thanks.  Here is the latest version of the patch, including your fixes.
I've started to add runtime testcases, but already the first one fails
due to issue 1) below.  The lastprivate case is hopefully resolved now
and we already seem to generate correct (and vectorized) code for say:
__attribute__((noinline, noclone)) int
foo2 (int *p)
{
  int i, s = 0;
  #pragma omp simd aligned(a, p : 32) reduction(+:s) lastprivate(l)
  for (i = 0; i < 1024; i++)
    {
      a[i] *= p[i];
      s += p[i] + k + (i + 1) * (m + 1);
      l = a[i] + p[i] + i;
    }
  return s;
}

Issues I'm struggling with are:
1) The linear clause handling is broken, when each SIMD lane has its
   own private variable, the user code increments that variable by
   whatever the loop body does (which must be equal to the declared
   linear_step), but that is only correct if vectorization factor
   is 1, because otherwise we need to still increment it somewhere by
   the remaining linear_step * (vf - 1).  The array approach is still
   needed at least for the case where the address of the linear privatized
   var is taken, but also because of vectorizer deficiencies.
   For the linear handling, one approach would be to assign the magic
   array element at the start of the loop body to loop iteration #
   times linear step (roughly matching foo function below), this one
   is vectorized, but suboptimal.  Another approach is just have another
   IV that contains the right value, hoping the vectorizer would do the
   expected thing and add vf * (m + 1) to a new vector IV, but the
   vectorizer just gives up on this.  And the last approach would be to
   keep the original user's increment in the loop and add another
   GOMP_SIMD_VF () * linear_step increment somewhere (beginning of the
   loop body (with corresponding adjustment of the initial vals) or
   at the end of the loop body (with a corresponding correction after
   the loop for the final value).  But, as baz function below (everything
   -O3 -mavx2) shows, we don't even merge the two additions and end up
   with two increments even in the vectorized loop (even for signed types,
   I believe if neither x += k nor x += 3 * k overflows, then x += 4 * k
   shouldn't overflow either.  So any preferences what code would be best
   for vectorization?
int a[1024] __attribute__((aligned (32)));
void foo (int k, int m) { int i; for (i = 0; i < 1024; i++) a[i] = k + i * (m + 1); }
void bar (int k, int m) { int i, k2 = k; for (i = 0; i < 1024; i++) { a[i] = k2; k2 += m + 1; } }
void baz (int k, int m) { int i; for (i = 0; i < 1024; i++) { a[i] += k; a[i] += 3 * k; } }

2) the magic array approach still creates too many variables in memory
   which aren't promoted to registers only.  The patch has code to shrink
   the arrays to the actual vectorization factor, but still say int[1]
   is not a GIMPLE type.  Any suggestions how to improve this?
   Already for the shrinking the code looks for all uses of the magic
   GOMP_SIMD_{VF,LANE,LAST_LANE} internal builtins and I need to walk
   the whole IL to find those, perhaps another alternative would be
   just to walk all stmts in the function before vectorization, looking
   say using walk_gimple_op for all stmts mentioning the magic
   "omp simd array" temporary arrays, and note whether all of them
   are convertible from the array representation to something else,
   note those in a hash table and then just after vectorization transform
   all that can be safely transformed (if they have vf 1 to just scalar
   vars with tweaking all uses, for vf > 1 into vectors, and just keep
   what has been addressable as arrays).

3) for better vectorization results, at least for now I think we'll want
   to use the array approach even for private iteration vars in collapse>1
   loops, as they don't seem to be vectorizable right now otherwise
   (vectorizer not liking the PHIs).

	Jakub

[gomp4] Some progress on #pragma omp simd

Commit Message

Patch