Re: [gomp4, WIP] Elementals improvements

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Nov 15, 2013 at 05:48:27AM +1000, Richard Henderson wrote:
> Pointers are certainly a decent fallback that would always be compatible,
> but I wonder if we need go that far.
> 
> Each target will have a (set of) natural simdlen to which it vectorizes.  This
> is the set returned by autovectorize_vector_sizes.  That means we've got
> registers of those sizes, and probably parameter passing of those sizes will be
> efficient.  It's easy to split input parameters into multiples, as you've done;
> no reason this can't apply generically.

The problem is that if a target doesn't support target attribute (all
targets except x86_64/i686/powerpc* right now), what do you do if command
line options when compiling the #pragma omp declare simd definition don't
include target options needed for use of the supposedly vector registers the
ABI wants to pass the arguments or return value in?  What simd clones we
emit should not depend on the compiler ISA options, unless those are ABI
incompatible.
I admit I'm not very familiar with vector support on targets not listed
above (just fuzzy memories from sparc, where it seems from a quick test
that the vector arguments are passed in normal floating point registers,
right?  Thus it wouldn't need pointer fallback).  Absolutely no idea about
ARM, I'm always lost in the tons of ABI changing (and some non-ABI changing)
options there, aarch64 (does it always have vector registers?), mips, what
else has vectorization?  I guess it doesn't make sense to emit simd clones
on targets that don't support vectorization at all.

> It's the return value wider than the register size that's tricky.  Here I think
> we may be best off returning a struct/array and letting the base calling
> convention handle it.  Normally that _will_ be via a pointer, but sometimes
> that pointer will be in some special non-parameter register.  Thus I think
> we're best off not performing the hidden argument conversion manually.

Shall it be array of vectors, array of the scalar types, struct with such
arrays?  I mean, do targets handle returning ARRAY_TYPE at all (does any FE
produce those)?

> We could generically use log2(vector_byte_size) + 'a' as the abi letter.
> 
> I'll look at the patches themselves later.

	Jakub