Re: generic vectors: how should they work?

[David Edelsohn <dje@watson.ibm.com>]

>>>>> Paolo Bonzini writes:

>> I think part of the problem is that the term "generic vector" is
>> being used for both arbitrary size vectors and synthetic (portable?) SIMD
>> modes.

Paolo> There are *no* synthetic SIMD modes.  SIMD modes are not used unless 
Paolo> supported by the hardware, and that's the change that prompted my famous
Paolo> patch.

	Either we are not using the term "synthetic SIMD mode" for the
same purpose or that comment is incorrect.

	gcc.dg/compat/vector-2 is failing on PowerPC because the port
cannot handle v16sf mode.  It does not exist in any PowerPC hardware, with
or without Altivec.  That is what I refer to as a synthetic SIMD mode.

	The lack of distinction between synthetic SIMD modes, such as
v16sf, and generic vectors is one of my fundamental concerns about your
current work.  Generic, arbitrary size vectors probably should be 1-D
arrays passed by reference, but that does not mean that all synthetic SIMD
modes should be passed by reference.

	There are two separate issues for the argument passing aspect of
your work:

1) How should synthetic SIMD modes be passed?

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

	In other words, v16sf could be four Altivec v4sf vectors grouped
together, like "long long int" grouping two 32-bit GPRs or could be a 1-D
array.  What is required, and what I expect, is some common controllable
ability to convert synthetic SIMD modes to generic vectors before the back
end has to manipulate them.

	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 should have explicit control
over generic vectors, be able to specify what synthetic SIMD modes it will
accept, and have the generic vector code convert them to 1-D arrays that
the port can pass by reference using it's default ABI.

David