Re: [gomp4, WIP] Elementals improvements

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Nov 15, 2013 at 06:26:28AM +1000, Richard Henderson wrote:
> On 11/15/2013 06:13 AM, Jakub Jelinek wrote:
> > 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?
> 
> Error or sorry.  We really have no other choice.

Well, that other choice is the pointer passing, perhaps tiny bit slower, but
it will just work.

In the patch right now a target hook let's decide what to do (with default
no SIMD clones at all).  We can easily provide say two generic
definitions of the target hook, one which uses pointers, one which uses
vector arguments, and let the target maintainers choose what is best for
them.

> I think it should be an array of vectors, ensuring that we can perform
> efficient aligned accesses to the array on both sides of the call.
> 
> I believe that Ada can return an ARRAY_TYPE.

Ok, will try that (though, likely only early next week, want to spend
another day on Asan tomorrow).

	Jakub