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. There is an element to these declare simd declarations that is inherently non-portable. You simply cannot use the same declarations for ARM that you can for AVX2. >> 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)? 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. But if in testing we find that fails for some reason, we can wrap the array in a struct. r~
