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 00:55:16 -0500
- Subject: Re: front end changes for altivec
On Thursday, November 29, 2001, at 12:00 AM, Alexandre Oliva wrote:
> On Nov 27, 2001, Richard Henderson <rth@redhat.com> wrote:
>
>> On Tue, Nov 27, 2001 at 06:59:35PM -0600, Aldy Hernandez wrote:
>>> why can't you have sizeof((vector int))?
>
>> Oh, you mean vector_width == sizeof(vector int) / sizeof(int)?
>> Um, I guess that works.
>
>> But what do you do with
>
>> vector int x = (vector int){ 1, 2, 3, 4 };
>
>> when a vector is only two elements wide?
>
> 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.
While on the subject of vectors I also don't quite see the need for the
overloaded functions (like altivec specifies). Why can't we just say
that addition of vectors (IE c=a + b where c, a, b are vectors)
transforms into
(set (reg:V4SF <reg for c>) (plus:V4SF (reg:V4SF <reg for a>) (reg:V4SF
<reg for b>))).
This, is, after all, what the intrinsics end up generating anyway.
Are we just waiting for a devectorizing pass that splits vector modes
not supported by a target machine into supported vectors or non-vectors
(I'm not talking trying to map onto different element sized
vector/non-vectors, just smaller ones. Like 2 v2sf's for each v4sf, if
v2sf was supported by the target and v4sf was not)?
Or am i missing something somehow?
--Dan