Re: generic vectors: how should they work?

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Paolo Bonzini writes:

Paolo> It is not V16SFmode, it is BLKmode.  The fact that the name of the type 
Paolo> resembles that of GCC modes is confusing you.  The rs6000 backend does 
Paolo> not even have a V16SFmode, since vector modes are defined per-target.

	The mode may be block mode, but the type is a vector type that
does not correspond to a fundamental mode of the target.  For instance,
rs6000_return_in_memory depends on the type, not BLKmode.

>> 1) How should synthetic SIMD modes be passed?

Paolo> I'll interpret this as "how should generic vectors, wider than the 
Paolo> widest hardware-supported vector type, be passed?"

Paolo> My answer is "by reference.  When, and if, they will be supported by 
Paolo> hardware, there will be an appropriate -mabi= switch that may change 
Paolo> this rule."

>> 2) When should synthetic SIMD modes be converted to generic vectors with a
>> count?

Paolo> My answer is "always, if they are BLKmode".  Maybe you want to emit a 
Paolo> warning or an hard error if there is some ABI for the target whereby 
Paolo> that generic vector would be passed in a different way.

	If the target includes a SIMD unit with SF support narrower than
the requested width, we probably want to emulate v8sf as a pair of v4sf
and emulate v16sf as four v4sf.  At some crossover point we want to switch
from multiple SIMD vector registers to pointers, but the crossover is not
obvious.

	I do think it depends on what synthetic SIMD types versus generic
vector types we are trying to support.  Is it the largest SIMD type
supported by any target?  Is it 256 bytes?  512?  1024?

	This really is architecting an ABI for targets if they ever
increase the width of their SIMD units.

	Are you trying to create a portable set of SIMD types or generic
vectors?  There may not be a single best solution for both.

David