Re: front end changes for altivec

[Daniel Berlin <dan at cgsoftware dot com>]

On Thursday, November 29, 2001, at 01:33  AM, Alexandre Oliva wrote:

> On Nov 29, 2001, Daniel Berlin <dan@cgsoftware.com> 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 should be able to infer it.
>> After, all, all our vector modes are fixed size, and all the vector
>> extensions we are talking of supporting have fixed size registers.
>
> Nope, I'm talking about letting the program tell the array size it
> wants, but letting the compiler decide the vector size to use,
> regardless of the array size.
*this* is tricky.
Well, okay, it depends on how advanced you want to be when deciding what 
vector size to use.
Even then, thinks like selecting the minimum/maximum of a vector are 
going to be trickier (pick an odd sized vector, you end up with extra 
elements, that you have to know what to fill with so they don't affect 
the answer, if this is even possible).

>   Then, you get the compiler to use
> vector operations where available, but the code will work without
> changes on machines without vector support, or with vectors of
> different length.
>
You can do this without having non-fixed sized vectors.
It's easier to.
It's always going to be much harder to shoehorn things *into* vectors, 
because of alignment issues, etc.
With a non-fixed size vector, this is what you have to do in some cases.
If you just stick to v2, v4, v8, v16, etc, you can always split a v16 
into 2 v8's, a v2 into two non-vectors, etc.
You avoid the alignment issues, dependency fun, etc.
Trying to support non-fixed size vectors, for any non-power of 2, is a 
serious pain.
At least, this is my impression.
Maybe i'm completely off.

--Dan