[gomp4,WIP] Elementals improvements

Hi!

Here is my latest elemental tweaks patch.
While the patch has code to pass some argument in multiple vector arguments,
it doesn't have something similar for return types.  A lot of
decisions whether to create elemental clone is done in a target hook
(because, as long as we pass arguments in vector registers, it is quite
tied to the ABI for the particular CPU and most probably requires target
attribute support (which the hook now uses on i?86)).

As discussed earlier, if we strictly follow the Intel ABI for simds,
we run into various issues.  The clones then have to use __regcall calling
convention which e.g. mandates that on x86_64 up to 16 vector arguments
are passed in xmm/ymm registers (problem, because the dynamic linker
during lazy binding can clobber ymm8 through ymm15), requires up to 16
vector values returned in xmm/ymm registers (for e.g.
#pragma omp declare simd simdlen(16)
_Complex double foo (double);
) - we don't have infrastructure for that plus we'd need to teach backend(s)
about that new calling convention, and declares {x,y}mm4-7 for 32-bit
and {x,y}mm8-15 for 64-bit to be call saved (on 64-bit again there is a
problem with that because the dynamic linker may clobber that, plus
it is an issue for bt/up in the debugger (we don't save/restore those in
unwind info and how big vectors would we save; note, elementals aren't
allowed to throw or setjmp/longjmp (the standard doesn't mention
setcontext/swapcontext etc. though)).

So, shall we just use different ISA letters to make it clear we are ABI
incompatible with ICC?  How should we return values if we need wider
vector than hw supports it?  Returning just wider vector type has the
problem that it is ABI unstable, say if we have:
#pragma omp declare simd simdlen(4)
double foo (double);
if this is the SSE2 ISA variant (originally x ISA letter), then
if we return double V __attribute__((vector_size (32))); then if
the definition of that function is compiled with -mavx, it would be
returned in %ymm0, otherwise as BLKmode vector (with warning about
ABI changing).  So, do we want to return it as say structure
containing array of 4 doubles?  Or pass as hidden argument
pointer to 4 doubles?  Something different?

What shall be done for targets that don't support target attribute?
Currently the patch just doesn't create simd clones there (well, on ppc* it
could/should, because it supports it).  But say for
ARM/AArch64/MIPS/SPARC/etc.?  I wonder if the generic representation
just shouldn't be ISA 'a', which would pass all non-uniform/non-linear
arguments as pointers to array of simdlen elements, and ditto for return
value through first hidden argument.  For x86_64/i?86, because (at least on
a tiny benchmark I've tried) the pointer arguments variant is somewhat
slower, we would use ISA 'b', 'c', 'd' for SSE2/AVX/AVX2 (shall we do
anything for AVX512-F too?) if simdlen is in between 2 and 16, otherwise
we'd use 'a' and arrays too.

Perhaps for the future we'll also want some way how to say that
two SIMD clones could be aliases of each other (and which one to
use as the primary one), and as discussed earlier also thunks.

For the aliases, because the integer vector size is the same between
x and y and floating vector size is the same between y and Y, if you
have say int (int, int) simd, then the calling convention is the same
between x and y, similarly for float (double, float) simd between y and Y.

Testcases I've been using are e.g.:
/* { dg-do options "-Ofast -fopenmp -mavx" } */

#pragma omp declare simd notinbranch
__attribute__((noinline)) float
foo (float a, float b, float c)
{
  return a + b + c;
}

float a[1024], b[1024], c[1024];

int
main ()
{
  int i, j;
  asm volatile ("" : : : "memory");
  for (j = 0; j < 10000000; j++)
    #pragma omp simd
    for (i = 0; i < 1024; i++)
      c[i] = foo (a[i], b[i], c[i]);
  return 0;
}
and corresponding 'a' ISA hand written variant (-Ofast -mavx):
typedef float V __attribute__((vector_size (32)));

__attribute__((noinline)) void
foo (V *ret, V *a, V *b, V *c)
{
  *ret = *a + *b + *c;
}

float a[1024], b[1024], c[1024];

int
main ()
{
  int i, j;
  asm volatile ("" : : : "memory");
  for (j = 0; j < 10000000; j++)
    for (i = 0; i < 1024; i += 8)
      {
        V rt, at, bt, ct;
        at = *(V *)&a[i];
        bt = *(V *)&b[i];
        ct = *(V *)&c[i];
        foo (&rt, &at, &bt, &ct);
        *(V *)&c[i] = rt;
      }
  return 0;
}
or compile time testcase:
/* { dg-do options "-O3 -fopenmp -mavx2" } */

#pragma omp declare simd
#pragma omp declare simd uniform(b) linear(c:3)
__attribute__((noinline)) short
foo (int a, long int b, short c)
{
  if (a == b + c)
    return 5;
  else
    return 6;
}

int a[1024];
long int b[1024];
short c[1024];

void
bar (int x)
{
  int i;
  if (x == 0)
    {
      #pragma omp simd
      for (i = 0; i < 1024; i++)
        c[i] = foo (a[i], b[i], c[i]);
    }
  else
    {
      #pragma omp simd
      for (i = 0; i < 1024; i++)
        c[i] = foo (a[i], x, i * 3);
    }
}

This one actually ICEs (see below), but if s/, short c/, int c/, then it
works.

The issue with the ICE is that apparently for short/char at GIMPLE the
function is called with promoted type instead, I guess handling type
demotion in vectorizable_simd_clone_call is too hard and ugly, so perhaps
we should bail there in such cases and have pattern recognizer transform
the foo (x, y, (int) z); call into foo (x, y, z); (or add cast if it isn't
result of earlier promotion).

Another thing to do is if we don't have a body for elemental function,
we still want to just create cgraph clone of it and create a FUNCTION_DECL
for it with modified arguments.

Also, as the Intel ABI says the mask is a vector of characteristic type of
the function, if it is float or double, I wonder if for -mavx it won't
force smaller vectorization factor (the code right now just
VIEW_CONVERT_EXPRs it to corresponding integer, because the mask shall be
either all 0s or all 1s).

	Jakub

[gomp4,WIP] Elementals improvements

Commit Message

Comments

Patch