This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: front end changes for altivec
- From: Daniel Berlin <dan at cgsoftware dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Aldy Hernandez <aldyh at redhat dot com>, Stan Shebs <shebs at apple dot com>, "Joseph S. Myers" <jsm28 at cam dot ac dot uk>, gcc at gcc dot gnu dot org
- Date: Thu, 29 Nov 2001 02:00:42 -0500
- Subject: Re: front end changes for altivec
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