generic vectors: how should they work?

[Janis Johnson <janis187 at us dot ibm dot com>]

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