generic vectors: how should they work?

generic vectors: how should they work?

[Janis Johnson]

GCC's generic vector extension is not clearly specified.  I've been
playing around to find out how this stuff works now and asking lots of
questions of Paolo Bonzini, who currently knows the most about the
extension.  Here's my summary of how things seem to work, which parts
need fixing, and some of the biggest holes.  My goal is to get the right
people (whoever you might be) to help tighten the specification and fill
the holes.

Christine Lorenz is planning to rewrite the section of the GCC Manual
that describes this extension, so I've copied her.  She's on vacation
this week.

I'll be taking off for four weeks starting September 4.  If anyone is
inspired to take over figuring out how this stuff is supposed to work,
feel free; otherwise I'll pick it up when I return.

I don't have strong feelings about how generic vectors ought to work, or
even whether they should be supported at all.  Any extension ought to be
documented and tested; otherwise we'll confuse users who stumble upon
them, think they look useful, and then complain when the features don't
work as expected.

Janis


why use generic vectors?

  allow portable code to use hardware vector support on multiple
  architectures (is this significantly different from using arrays in
  simple loops that can be vectorized?)

declaration of vector variable

  base types: float, double, any integral scalar type

  const, volatile qualifiers can appear anywhere

  __attribute__((vector_size(N))) can appear anywhere

  vector size is the number of bytes in the vector, must be power of two

  limit on vector size is 256 elements (bug: currently there's an ICE,
  no error message from the front end)

operators

  binary arithmetic operators: +, -, *, /
  unary arithmetic operator:   -
  binary bitwise operators:    ^,|, &
  unary bitwise operator:      ~

  (bug: currently these don't work from C++)

  operations are performed on corresponding elements of the operands
  with the result stored in the corresponding element of the result

  limitations on types of operands are not well-specified

  requirements for casts are not well-specified

casts

  currently merely does bit copy from one vector object to another
  (what's the point?)

  cast that would coerce values when used on scalars should either
  coerce values on an element-by-element basis (like operators) or
  should be an error (bug: currently it merely does a bitwise copy
  between integer and floating point types)

  limit use of cast to vectors of the same size and/or vectors with
  the same number of elements?

assignment

  should assignment coerce values or merely move bits? (same issue
  as for cast)

alignment

  ABI issue; does this depend on whether a vector type has hardware
  support?  (should always be aligned on processor families that support
  vectors, even if the specific target doesn't, for interoperability)

arguments and function results

  depends on ABI, which might specify that they are handled differently
  depending on whether a vector is a hardware vector (ABIs don't yet
  cover this)

  passing pointers by value might not be interoperable between modules
  compiled with and without hardware vector support; more portable to
  pass vectors via pointers

mapping to hw vectors, optimizations, tuning

  a vector whose type is supported by the target hardware is treated the
  same as if it had been defined using the target's builtin __vector
  keyword

  a vector that is larger than what the target hardware supports and
  whose base type is supported by hardware vectors is constructed from
  multiple hardware vectors; what this mean depends on the ABI (although
  ABIs don't currently cover this)

  anything else is handled by software (bug: vectors smaller than what's
  supported by hardware try to use hw vectors on powerpc64-linux)

  in practice, vectors with 16 or more elements are inefficient

implementation details should be covered in the GCC Internals Manual

Re: generic vectors: how should they work?

[David Edelsohn]

	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.  These are not necessarily the same thing and the implementation is
not necessarily the same for both.

David

Re: generic vectors: how should they work?

[Paolo Bonzini]

> 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.

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

Paolo

Re: generic vectors: how should they work?

[David Edelsohn]

>>>>> 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

Re: generic vectors: how should they work?

[Paolo Bonzini]

[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

Re: generic vectors: how should they work?

[Giovanni Bajo]

Paolo Bonzini wrote:

> It is not V16SFmode, it is BLKmode.  [...]

This stuff *ought* to be properly documented in the internal manual.

Giovanni Bajo

Re: generic vectors: how should they work?

[Paolo Bonzini]

> This stuff *ought* to be properly documented in the internal manual.

Not that the old stuff was documented in any way :-/  I'm going to do 
that at the same time Janis Johnson and Christine Lorenz work on the 
user manual.

Paolo

Re: generic vectors: how should they work?

[Richard Henderson]

On Wed, Sep 01, 2004 at 05:18:04PM +0200, Paolo Bonzini wrote:
> 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."

I would argue that a generic vector should be passed as if it's
a struct containing N elements of the appropriate type.  Which 
is *not* pass-by-reference on many targets.



r~

Re: generic vectors: how should they work?

[James E Wilson]

Janis Johnson wrote:
> GCC's generic vector extension is not clearly specified.  I've been
> playing around to find out how this stuff works now and asking lots of
> questions of Paolo Bonzini, who currently knows the most about the
> extension.  Here's my summary of how things seem to work, which parts
> need fixing, and some of the biggest holes. 

I think the biggest hole is the lack of an operator to extract an 
element from a vector.  If you want target independent code to extract 
an element from a vector, then you have to use a union.  However, once 
you use a union, you no longer have vector operations, and can't use the 
hardware vector instructions.  Instead, what happens is that the vector 
gets forced into a stack slot so we can index into it.  Maybe we could 
reuse the array syntax for this, e.g vector[0] to extract the first 
element of the vector?

> operators

There is also an initializer/constructor syntax that you didn't mention.
   (type) { element, ... }

>   (bug: currently these don't work from C++)

This is PR 10611, which incidentally contains a patch that makes trivial 
testcases work.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: generic vectors: how should they work?

[David Edelsohn]

>>>>> James E Wilson writes:

James> I think the biggest hole is the lack of an operator to extract an 
James> element from a vector.  If you want target independent code to extract 
James> an element from a vector, then you have to use a union.  However, once 
James> you use a union, you no longer have vector operations, and can't use the 
James> hardware vector instructions.  Instead, what happens is that the vector 
James> gets forced into a stack slot so we can index into it.  Maybe we could 
James> reuse the array syntax for this, e.g vector[0] to extract the first 
James> element of the vector?

	Honza submitted a patch to implement additional init/set/extract
expanders, but the second patch never was reviewed.

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00050.html

David

Re: generic vectors: how should they work?

[James E Wilson]

On Wed, 2004-09-01 at 13:40, David Edelsohn wrote:
> 	Honza submitted a patch to implement additional init/set/extract
> expanders, but the second patch never was reviewed.
> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00050.html

That is an x86 backend patch, which doesn't help a mips user much.  I
was looking for front-end/middle changes to add syntax that would
translate into vec_init/vec_set/vec_extract calls.  We have the
constructor syntax that turns into vec_init, but we have no syntax that
turns into vec_set or vec_extract.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: generic vectors: how should they work?

[David Edelsohn]

>>>>> 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

Re: generic vectors: how should they work?

[Janis Johnson]

On Wed, Sep 01, 2004 at 10:49:21AM -0400, David Edelsohn wrote:
> >>>>> 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.

What's the right term for each of these?

  1) a vector type that is directly supported by the hardware (vector
     size and base type)

  2) a vector type that can be composed of multiple hardware-supported
     vectors (larger than hardware vector size, base type is supported)

  3) any other vector type (too small or else base type is not
     supported by hardware vectors)

  4) a type with attribute vector_size as described in the GCC Manual,
     which might be any of the above depending on how it is compiled

Janis

Re: generic vectors: how should they work?

[Richard Henderson]

On Wed, Sep 01, 2004 at 01:12:12PM -0700, James E Wilson wrote:
> Maybe we could reuse the array syntax for this, e.g vector[0] to extract
> the first element of the vector?

That would work for me.


r~

Re: generic vectors: how should they work?

[Paolo Bonzini]

> 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."

rth's answer is more precise and appropriate.  Of course I agree with 
him -- pending the introduction of new special ABI conventions for wide 
vectors, if hardware starts supporting them.

Note that all backends but rs6000 have no problems with wide vector 
types: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00379.html includes 
a survey of that.

rs6000 does not know about non-aggregate types of BLKmode: in rs6000.c, 
aggregates are passed in memory if bigger than 8 bytes, but vectors are not.

> 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.

While we do that at the arithmetic level, if the vectors are big enough 
to be BLKmode the values will always be stored in memory and never in 
several registers.

> Are you trying to create a portable set of SIMD types or generic
> vectors?

I don't understand this comment.  I see SIMD types as a synonym of 
vectors.  "Portable vectors", "generic vectors", "portable SIMD types", 
"generic SIMD types" seem all synonyms to me.

Paolo

Re: generic vectors: how should they work?

[David Edelsohn]

>>>>> Paolo Bonzini writes:

Paolo> I don't understand this comment.  I see SIMD types as a synonym of 
Paolo> vectors.  "Portable vectors", "generic vectors", "portable SIMD types", 
Paolo> "generic SIMD types" seem all synonyms to me.

	I thought that I already explained the distinction in the previous
messages.

David

Re: generic vectors: how should they work?

[Paolo Bonzini]

> Paolo> I don't understand this comment.  I see SIMD types as a synonym of 
> Paolo> vectors.  "Portable vectors", "generic vectors", "portable SIMD types", 
> Paolo> "generic SIMD types" seem all synonyms to me.
> 
> 	I thought that I already explained the distinction in the previous
> messages.

If you meant generic vectors as in, arbitrarily sized and/or with a size 
decided at run-time, then no, this is not my purpose.  GCC portable SIMD 
types (this is your nomenclature if I understood) have their size 
established at compile-time, and it must be a power of two.

Paolo

Re: generic vectors: how should they work?

[Janis Johnson]

On Wed, Sep 01, 2004 at 04:47:00PM -0700, Janis Johnson wrote:
> On Wed, Sep 01, 2004 at 10:49:21AM -0400, David Edelsohn wrote:
> > >>>>> 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.
> 
> What's the right term for each of these?

How about these?
 
>   1) a vector type that is directly supported by the hardware (vector
>      size and base type)

       hardware SIMD type

>   2) a vector type that can be composed of multiple hardware-supported
>      vectors (larger than hardware vector size, base type is supported)

       synthetic SIMD type

>   3) any other vector type (too small or else base type is not
>      supported by hardware vectors)

       software vector type (need something better for this one)

>   4) a type with attribute vector_size as described in the GCC Manual,
>      which might be any of the above depending on how it is compiled

       generic vector

Janis

Re: generic vectors: how should they work?

[Janis Johnson]

On Thu, Sep 02, 2004 at 03:09:42PM +0200, Paolo Bonzini wrote:
> >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."
> 
> rth's answer is more precise and appropriate.  Of course I agree with 
> him -- pending the introduction of new special ABI conventions for wide 
> vectors, if hardware starts supporting them.
> 
> Note that all backends but rs6000 have no problems with wide vector 
> types: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00379.html includes 
> a survey of that.
> 
> rs6000 does not know about non-aggregate types of BLKmode: in rs6000.c, 
> aggregates are passed in memory if bigger than 8 bytes, but vectors are not.
> 
> >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.
> 
> While we do that at the arithmetic level, if the vectors are big enough 
> to be BLKmode the values will always be stored in memory and never in 
> several registers.
> 
> >Are you trying to create a portable set of SIMD types or generic
> >vectors?
> 
> I don't understand this comment.  I see SIMD types as a synonym of 
> vectors.  "Portable vectors", "generic vectors", "portable SIMD types", 
> "generic SIMD types" seem all synonyms to me.

Here's a question that probably shows the extent of my ignorance: could
the back end determine the type for a specific generic vector that could
be quite different on powerpc, x86, or mips hardware, or on hardware
with no vector support?  The same generic vector type might be

  a hardware SIMD type
  a synthetic SIMD type (constructed of multiple hardware SIMD types)
  an array of the vector's base type
  an array of hardware SIMD types
  an array of synthetic SIMD types
  a struct with members of the vector's base type
  a struct with members of hardware SIMD types
  ...

Information about generic vectors in the GCC Manual should not depend
on how they are implemented on various platforms, although the
implementation details should be covered in the internals manual.  There
should be a default way to implement generic vectors, particularly for
argument passing, with anything else covered in platform-specific  ABIs.

Janis