Re: front end changes for altivec

[Per Bothner <per at bothner dot com>]

Alexandre Oliva wrote:

> How about requiring that variables of type vector always be arrays
> with their actual number of elements explicitly specified, or inferred
> from the initializer?
> 
> We could still support implicit iteration over vector elements for
> operations such as copying, addition and subtraction, relieving the
> source code from the need to worry about the exact vector size, while
> still allowing code to pick into it somehow, for example:
> 
> vector int x[] = { 1, 2, 3, 4, 5, 6, 7 }; // probably pads with 0s
> 
> vector int y[7];
> 
> ...
> 
>   y = x;
>   y = x + y; 

My recommendation is to define the extension as syntactic sugar
for a C++ template.  That has the advantage of providing a clean definition.

There happens to be a standard C++ template that seems to closely
match what is needed:  valarray.  This was specifically designed
to be highly optimizable and to be mapped to vector hardware.

My preference:

* We provide hooks so that valarray implementations can run
optimized on suitable hardware, including Altivec and MMX.

* We encourage programmers who want to write efficient code
to use C++ and the valarray type.  They gain the benefits of
making their code both portable and fast.

* If we define a C "vector" extension we define in terms of
the C++ valarray type.  Specifically, there should be no
Altivec-target-dependent functionality or optimizations
that you can access from the C extension that you can't also
access using the valarray template in C++.  I want to encourage
people to write clean portable code, not some kludge.  A
pre-processor that translates from Alticvec C into valarray-using
C++ code would be my preference.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/