Re: front end changes for altivec

[Jack Lloyd <lloyd at acm dot jhu dot edu>]

On Thu, 29 Nov 2001, Daniel Berlin wrote:

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

Maybe I'm completely off base here, but a pretty sane interpretation of a 9
element unsigned char vector on a machine with (for example) MMX, could be
a single 8 byte long MMX vector along with a single unsigned char. OTOH,
that could be very hard from an actual implementation perspective, I'm no
GCC internals expert (obviously).

BTW, one question about this: is it really reasonble to support essentially
arbitrary length vectors like this? I kind of get the feeling it would be
better for something working on a somewhat higher level (like libstdc++
valarray or a GMP-like library). For example, I can't get arbitrary size
integers with GCC, why should I be able to get abitrary size vectors?

Not meaning to start a flame war or anything (more than has already been
started in this thread <g>), just some thoughts/questions I had...

-Jack