Re: generic vectors: how should they work?

[Paolo Bonzini <bonzini@gnu.org>]

[Taking Christine Lorenz off the recipient list]

> 	gcc.dg/compat/vector-2 is failing on PowerPC because the port
> cannot handle v16sf mode.

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

> 1) How should synthetic SIMD modes be passed?

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

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

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

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

> 	I believe that it is a fundamental interface design flaw for the
> backend to have to deal with arbitrary synthetic vector modes in the
> argument passing target hooks.

The backend only sees BLKmode.  I have stated this several times, 
together with these other facts:

1) the backend used to see vector modes when the AltiVec instructions 
are disabled, it does not anymore.  A vector modes is only used if there 
are registers of that mode available.

2) even if vector instructions are available, again vector modes are not 
used if there are registers of that mode available.  Even if V16SFmode 
were defined for rs6000, it would make no difference, the backend would 
see BLKmode.

Paolo