This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: front end changes for altivec

On Thursday, November 29, 2001, at 12:00  AM, Alexandre Oliva wrote:

> On Nov 27, 2001, Richard Henderson <> 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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]