Re: front end changes for altivec

Re: front end changes for altivec

[mike stump]

> Date: Tue, 27 Nov 2001 14:50:22 -0800
> From: Stan Shebs <shebs@apple.com>
> To: Richard Henderson <rth@redhat.com>

> You mean like how we don't have machine-dependent sizes for int
> and long int?

If in the end we have a portable thing that users can use in a fairly
simple and straight forward way, that allows them to switch from a mmx
machine to an sse machine, to an sse2 machine, to a ...  machine, we
win.  A good design is also forward compatible with strange hardware
that might come up in the future, or strange new operations...

On a good number of machines, almost all that matter, int is 32 bits,
long int is 32 bits.  I can't help but wonder if C would have been a
better standard, if they had just outright said, ints are 32 bits,
period.  It would have removed one major source of confusion and
increased (in a theoretical sense only) the portability of user code.

I can't help but think that code that does:

vector<int[4]> a, b;

int foo() { a += b; }

is intrinsically better than

vector<int> a, b;

int foo() { a += b; }

We can engineer gcc to have the first work on all machines, quickly on
some, `normal' speed on the rest.  C++ people, don't let the second
confuse you into thinking of std::vector, it is totally different.
Think gnu::gcc::vector.

In reading code like:

vector<int[32]> a, b;

int foo() { a += b; }

I can say, wow, someone has an arm core with a beefy vector unit
attached on an ASIC and I bet this puppy smokes.  I can also know that
I could compile it up as portable C code, and it would run on anything
GNU C supports, though, I might want a faster box in the end (bearing
in mind that sizeof(int)==4).

Re: front end changes for altivec

[mike stump]

> Date: Tue, 27 Nov 2001 14:50:22 -0800
> From: Stan Shebs <shebs@apple.com>
> To: Richard Henderson <rth@redhat.com>

> You mean like how we don't have machine-dependent sizes for int
> and long int?

If in the end we have a portable thing that users can use in a fairly
simple and straight forward way, that allows them to switch from a mmx
machine to an sse machine, to an sse2 machine, to a ...  machine, we
win.  A good design is also forward compatible with strange hardware
that might come up in the future, or strange new operations...

On a good number of machines, almost all that matter, int is 32 bits,
long int is 32 bits.  I can't help but wonder if C would have been a
better standard, if they had just outright said, ints are 32 bits,
period.  It would have removed one major source of confusion and
increased (in a theoretical sense only) the portability of user code.

I can't help but think that code that does:

vector<int[4]> a, b;

int foo() { a += b; }

is intrinsically better than

vector<int> a, b;

int foo() { a += b; }

We can engineer gcc to have the first work on all machines, quickly on
some, `normal' speed on the rest.  C++ people, don't let the second
confuse you into thinking of std::vector, it is totally different.
Think gnu::gcc::vector.

In reading code like:

vector<int[32]> a, b;

int foo() { a += b; }

I can say, wow, someone has an arm core with a beefy vector unit
attached on an ASIC and I bet this puppy smokes.  I can also know that
I could compile it up as portable C code, and it would run on anything
GNU C supports, though, I might want a faster box in the end (bearing
in mind that sizeof(int)==4).

Re: front end changes for altivec

[Daniel Berlin]

On Thursday, November 29, 2001, at 02:16  AM, Richard Henderson wrote:

> On Thu, Nov 29, 2001 at 12:55:16AM -0500, Daniel Berlin wrote:
>> 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>))).
>
> Yes, that's lovely.  Now what about, say, saturating adds?
>
>
> r~
Anything that doesn't map easily onto rtl requires builtins.
--Dan

Re: front end changes for altivec

[Jack Lloyd]

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

Re: front end changes for altivec

[Richard Henderson]

On Thu, Nov 29, 2001 at 12:55:16AM -0500, Daniel Berlin wrote:
> 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>))).

Yes, that's lovely.  Now what about, say, saturating adds?


r~

Re: front end changes for altivec

[Daniel Berlin]

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

Re: front end changes for altivec

[Alexandre Oliva]

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

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: front end changes for altivec

[Per Bothner]

Alexandre Oliva 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 could still support implicit iteration over vector elements for
> operations such as copying, addition and subtraction, relieving the
> source code from the need to worry about the exact vector size, while
> still allowing code to pick into it somehow, for example:
> 
> vector int x[] = { 1, 2, 3, 4, 5, 6, 7 }; // probably pads with 0s
> 
> vector int y[7];
> 
> ...
> 
>   y = x;
>   y = x + y; 

My recommendation is to define the extension as syntactic sugar
for a C++ template.  That has the advantage of providing a clean definition.

There happens to be a standard C++ template that seems to closely
match what is needed:  valarray.  This was specifically designed
to be highly optimizable and to be mapped to vector hardware.

My preference:

* We provide hooks so that valarray implementations can run
optimized on suitable hardware, including Altivec and MMX.

* We encourage programmers who want to write efficient code
to use C++ and the valarray type.  They gain the benefits of
making their code both portable and fast.

* If we define a C "vector" extension we define in terms of
the C++ valarray type.  Specifically, there should be no
Altivec-target-dependent functionality or optimizations
that you can access from the C extension that you can't also
access using the valarray template in C++.  I want to encourage
people to write clean portable code, not some kludge.  A
pre-processor that translates from Alticvec C into valarray-using
C++ code would be my preference.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: front end changes for altivec

[Daniel Berlin]

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

Re: front end changes for altivec

[Alexandre Oliva]

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 could still support implicit iteration over vector elements for
operations such as copying, addition and subtraction, relieving the
source code from the need to worry about the exact vector size, while
still allowing code to pick into it somehow, for example:

vector int x[] = { 1, 2, 3, 4, 5, 6, 7 }; // probably pads with 0s

vector int y[7];

...

  y = x;
  y = x + y; 

I'm unsure whether indexing such an array (x[n]) would get you the nth
int or the nth vector element.  I'm inclined to prefer the latter,
even though it's a bit odd that you wouldn't be able to get x[6] on
the vector above unless the machine didn't support any int-type vector
mode, such that the int vector size is 1.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 07:26:34PM -0600, Aldy Hernandez wrote:
> > Modulo the varying size of "short",
> > 
> >   #define __vector  __attribute__((__vector_size__(16)))
> 
> the thing is that there are builtins that expect V4SI, or V4SF, or
> V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
> and cast them (which does nothing, but quiets the parser).

Examine the type that __vector is modifying ("short" for this example)
and you get HImode.  Divide vector_size(16) by sizeof(HImode) to yield 8.
Put it all together and to get V8HImode.  Voila.


r~

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 05:40:11PM -0800, Dale Johannesen wrote:
> I come from a BE background, so to me a single mode for all
> 16-byte vector objects seems cleanest, but I'm sure people from
> FE backgrounds would disagree.

This falls down for operations such as saturating addition --
you have to know what the element width is, so that you can
choose the proper instruction.


r~

Re: front end changes for altivec

[Dale Johannesen]

On Tuesday, November 27, 2001, at 05:26 PM, Aldy Hernandez wrote:
>
> the thing is that there are builtins that expect V4SI, or V4SF, or
> V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
> and cast them (which does nothing, but quiets the parser).
>
> actually, why can't we do this then:
>
> 	#define __vector  __attribute__ ((mode(V4SI)))
>
> i still would like to have different modes for different vector types
> (short, int, char).

I got this working both ways and eventually let all vectors be V16QI.
That removes some bloat in rs6000.md and there are somewhat fewer
changes in the target-independent parts of the code (e.g. for casts).
The other way is certainly more convenient for resolving those builtins,
though.  I come from a BE background, so to me a single mode for all
16-byte vector objects seems cleanest, but I'm sure people from
FE backgrounds would disagree.

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:01, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 06:52:55PM -0600, Aldy Hernandez wrote:
> > > How about __vector_size__(16) then?
> > 
> > can anyone think of any way to get:
> > 
> > 	vector int foo;		/* v4si */
> > 	vector short bar;	/* v2hi */
> > 	vector char hot;	/* v16qi */
> > 	etc
> > 
> > working for altivec in a target independent manner?
> 
> Modulo the varying size of "short",
> 
>   #define __vector  __attribute__((__vector_size__(16)))

the thing is that there are builtins that expect V4SI, or V4SF, or
V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
and cast them (which does nothing, but quiets the parser).

actually, why can't we do this then:

	#define __vector  __attribute__ ((mode(V4SI)))

i still would like to have different modes for different vector types
(short, int, char).


> 
> works.  And char/short/int doesn't actually vary *that* widely.
> The targets for which these are not 1, 2 and 4 octets wide are
> fairly rare, so I'm willing to gloss over that.  Especially
> since you can also work around this like so:
> 
> 	#if SHRT_MAX == 32767
> 	typedef unsigned short u16;
> 	#elif INT_MAX == 32767
> 	typedef unsigned int u16;
> 	#else
> 	#error you're strange
> 	#endif
> 
> 	__vector u16 foo;
> 
> I think for stuff written for gcc itself we should encourage the use
> of mode(V4SI), or some other explicit element size + vector width
> syntax yet to be determined.
> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 07:12:31PM -0600, Aldy Hernandez wrote:
> > But what do you do with
> > 
> > 	vector int x = (vector int){ 1, 2, 3, 4 };
> > 
> > when a vector is only two elements wide?
> 
> that should trigger a syntax error.  and vector constants should only be
> used in initializers.

Then how do you initialize _any_ data across different simd
implementations?


r~

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:03, 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.

right

> But what do you do with
> 
> 	vector int x = (vector int){ 1, 2, 3, 4 };
> 
> when a vector is only two elements wide?

that should trigger a syntax error.  and vector constants should only be
used in initializers.
> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Richard Henderson]

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?


r~

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 06:52:55PM -0600, Aldy Hernandez wrote:
> > How about __vector_size__(16) then?
> 
> can anyone think of any way to get:
> 
> 	vector int foo;		/* v4si */
> 	vector short bar;	/* v2hi */
> 	vector char hot;	/* v16qi */
> 	etc
> 
> working for altivec in a target independent manner?

Modulo the varying size of "short",

  #define __vector  __attribute__((__vector_size__(16)))

works.  And char/short/int doesn't actually vary *that* widely.
The targets for which these are not 1, 2 and 4 octets wide are
fairly rare, so I'm willing to gloss over that.  Especially
since you can also work around this like so:

	#if SHRT_MAX == 32767
	typedef unsigned short u16;
	#elif INT_MAX == 32767
	typedef unsigned int u16;
	#else
	#error you're strange
	#endif

	__vector u16 foo;

I think for stuff written for gcc itself we should encourage the use
of mode(V4SI), or some other explicit element size + vector width
syntax yet to be determined.


r~

Re: front end changes for altivec

[Aldy Hernandez]

> 
> Except that I think this is much worse.  At least for "int" you
> have sizeof, INT_MAX, CHAR_BITS etc to determine the nature of
> the type on the machine.  I think we can do better for vectors.

why can't you have sizeof((vector int))?

> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 16:00, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> > not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> > "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> > to a given vector size because that depends on the type being vectored.
> 
> How about __vector_size__(16) then?
> 
> > and then have a default for the given backend+target_switches...
> 
> Absolutely not.  No machine dependant defaults.  You can't take
> that source to another machine.

can anyone think of any way to get:

	vector int foo;		/* v4si */
	vector short bar;	/* v2hi */
	vector char hot;	/* v16qi */
	etc

working for altivec in a target independent manner?

if not, it pretty much looks like we need separate non-fsf patches to
get this to work.

> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 02:50:22PM -0800, Stan Shebs wrote:
> > Absolutely not.  No machine dependant defaults.  You can't take
> > that source to another machine.
> 
> You mean like how we don't have machine-dependent sizes for int
> and long int?

Exactly!  All the world's a VAX!  ;-)  

Except that I think this is much worse.  At least for "int" you
have sizeof, INT_MAX, CHAR_BITS etc to determine the nature of
the type on the machine.  I think we can do better for vectors.


r~

Re: front end changes for altivec

[Stan Shebs]

Richard Henderson wrote:
> 
> On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> > not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> > "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> > to a given vector size because that depends on the type being vectored.
> 
> How about __vector_size__(16) then?
> 
> > and then have a default for the given backend+target_switches...
> 
> Absolutely not.  No machine dependant defaults.  You can't take
> that source to another machine.

You mean like how we don't have machine-dependent sizes for int
and long int?

:-)

Stan

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> to a given vector size because that depends on the type being vectored.

How about __vector_size__(16) then?

> and then have a default for the given backend+target_switches...

Absolutely not.  No machine dependant defaults.  You can't take
that source to another machine.


r~

Re: front end changes for altivec

[Aldy Hernandez]

> I prefer
> 
> 	int foo __attribute__((vector(4)));
> 
> which, iirc, also works as a prefix,
> 
> 	__attribute__((vector(4))) int foo;
> 
> which, with appropriate cpp magic in <altivec.h> becomes
> 
> #define __vector  __attribute__((__vector__(4)))
> 
> 	__vector int foo;

not good, because we have "vector int" (V4SI), "vector short" (V8HI),
"vector char" (V16QI), etc.  we can't just define "__vector" to expand
to a given vector size because that depends on the type being vectored.

i still prefer :):

	__vector(4) int foo;

and then have a default for the given backend+target_switches:

	__vector int foo;

a clean implementation IMO.

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 09:24:03AM -0600, Aldy Hernandez wrote:
> do we really need to specify a vector size?

Yes.  This documents the intention of the author of the code.

With such, one could write generic code to handle the case that
the machine does not support SIMD at all, or that the machine
supports SIMD but in a narrower mode written in the source.

It also lets the author write code with larger vector sizes (8, 16, 32...)
and have the compiler automatically decompose into whatever the
machine can actually handle.  Which might possibly give the 
compiler more information and let it optimize better.  Dunno
for sure about that, but it's not implausable.

> 	vector(4) int foo;
> 	vector<4> int foo;

I prefer

	int foo __attribute__((vector(4)));

which, iirc, also works as a prefix,

	__attribute__((vector(4))) int foo;

which, with appropriate cpp magic in <altivec.h> becomes

#define __vector  __attribute__((__vector__(4)))

	__vector int foo;

which merely leaves you the c++ nastiness problem with
"vector" vs "__vector" vs "std::vector".


r~

Re: front end changes for altivec

[Aldy Hernandez]

> > > SSE is 128 bits.
> > 
> > sorry, mmx then.
> > 
> > which complicates things further... with this mmx and sse and sse2, what
> > would the default be for "vector int"?  mmx is 64bits (right?) and sse
> > is 128bits, so when we talk of vector int, what are we talking about.
> 
> I think all these problems show clearly that the extension is poorly thought
> out and should not be included in gcc.

that's why i brought up here first, so we can talk it through and
hopefully come up with a good design that can be used across all the
different simd architectures.

re the different sizes in x86 simd (mmx/sse/sse2), we could have the
default vector sizes depend on the macro i proposed.  the macro could
return different vector sizes based on TARGET_MMX/etc flags.  very
simple.

and if the user specifies:

	vector<2> int foo;

it can only mean V2SI in mmx if TARGET_MMX (and available) or V2SI in
sse* if TARGET_SSE* (and available).

i don't think it's that bad.

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Bernd Schmidt]

On 27 Nov 2001, Aldy Hernandez wrote:

> On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote:
> > Aldy Hernandez <aldyh@cygnus.com> writes:
> > 
> > >> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> > >> but this adds complications to the C grammar I don't really want there
> > >> since > can be part of a constant expression (so if going that way then do
> > >> as many as possible of defining disambiguating rules by reference to
> > >> existing practice, proving the existence or nonexistence of ambiguous
> > >> cases, describing how the parsing should be implemented).  Or use
> > >> "vector(4)".  Or add some other way of specifying a non-default vector
> > >
> > > i've thought about this some more.
> > >
> > > do we really need to specify a vector size?  simd architectures
> > > generally have a specific vector size, 64bits for sse* and 128bits for
> > > altivec.  
> > 
> > SSE is 128 bits.
> 
> sorry, mmx then.
> 
> which complicates things further... with this mmx and sse and sse2, what
> would the default be for "vector int"?  mmx is 64bits (right?) and sse
> is 128bits, so when we talk of vector int, what are we talking about.

I think all these problems show clearly that the extension is poorly thought
out and should not be included in gcc.


Bernd

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote:
> Aldy Hernandez <aldyh@cygnus.com> writes:
> 
> >> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> >> but this adds complications to the C grammar I don't really want there
> >> since > can be part of a constant expression (so if going that way then do
> >> as many as possible of defining disambiguating rules by reference to
> >> existing practice, proving the existence or nonexistence of ambiguous
> >> cases, describing how the parsing should be implemented).  Or use
> >> "vector(4)".  Or add some other way of specifying a non-default vector
> >
> > i've thought about this some more.
> >
> > do we really need to specify a vector size?  simd architectures
> > generally have a specific vector size, 64bits for sse* and 128bits for
> > altivec.  
> 
> SSE is 128 bits.

sorry, mmx then.

which complicates things further... with this mmx and sse and sse2, what
would the default be for "vector int"?  mmx is 64bits (right?) and sse
is 128bits, so when we talk of vector int, what are we talking about.

perhaps i should leave that to whomever adds the vector keyword stuff
for x86 :)

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Andreas Jaeger]

Aldy Hernandez <aldyh@cygnus.com> writes:

>> The answer from some quarters might be "vector int<4>" or "vector<4> int",
>> but this adds complications to the C grammar I don't really want there
>> since > can be part of a constant expression (so if going that way then do
>> as many as possible of defining disambiguating rules by reference to
>> existing practice, proving the existence or nonexistence of ambiguous
>> cases, describing how the parsing should be implemented).  Or use
>> "vector(4)".  Or add some other way of specifying a non-default vector
>
> i've thought about this some more.
>
> do we really need to specify a vector size?  simd architectures
> generally have a specific vector size, 64bits for sse* and 128bits for
> altivec.  

SSE is 128 bits.

But I agree, we should find a general solution!

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: front end changes for altivec

[Aldy Hernandez]

> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> but this adds complications to the C grammar I don't really want there
> since > can be part of a constant expression (so if going that way then do
> as many as possible of defining disambiguating rules by reference to
> existing practice, proving the existence or nonexistence of ambiguous
> cases, describing how the parsing should be implemented).  Or use
> "vector(4)".  Or add some other way of specifying a non-default vector

i've thought about this some more.

do we really need to specify a vector size?  simd architectures
generally have a specific vector size, 64bits for sse* and 128bits for
altivec.  

so, "vector int x" in sse* means V2SI, provided ints are 32bits.

in altivec, "vector int" means V4SI, provided ints are 32bits.

so do we _really_ need to specify a size or can it be determined from
backend info?

if we really do need to specify vector size, then either of your
proposals will work:

	vector(4) int foo;
	vector<4> int foo;

(i really don't like "vector int<4> foo" :))

what do you suggest <> or ()?

furthermore, we need to have a default vector size for the altivec stuff
to work-- and it makes for prettier code :).  so:

	vector int foo	--> V4SI in altivec
	vector int foo	--> V2SI in SSE*
	etc

we would need defaults for vector + [int, short, bool, char, float]. 
for this, we could add a macro to gcc that given an SI/HI/QI/SF returns
an V4SI/V8HI/V18QI/V4SF.  this seems like the cleanest idea.

how does this sound?

aldy

Re: front end changes for altivec

[Richard Henderson]

On Mon, Nov 26, 2001 at 05:50:04PM -0800, Aldy Hernandez wrote:
> yes, ideally.  but what do we do for the current specs which specifies
> parentheses?

Ignore them.


r~

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, Nov 27, 2001 at 01:04:05AM +0000, Joseph S. Myers wrote:
> On Mon, 26 Nov 2001, Aldy Hernandez wrote:
> 
> > __vector must be first among type specifiers.  the specs are rather skekchy,
> 
> That's not consistent with how other type specifiers work.  It would make
> more sense for the list of possible type specifier combinations to include
> such things as "__vector signed int" and any permutation thereof.

sure

> > ok, but how would we differentiate between the diff vector sizes.
> > altivec has "vector int" being V4SI, but vector int could mean V2SI in
> > mmx.  suggestion welcome while i think through this.
> 
> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> but this adds complications to the C grammar I don't really want there

i don't link this idea.

> as many as possible of defining disambiguating rules by reference to
> existing practice, proving the existence or nonexistence of ambiguous
> cases, describing how the parsing should be implemented).  Or use

i'm not sure i follow., can you give an example.

> "vector(4)".  Or add some other way of specifying a non-default vector
> size.

that could be better. 
> 
> > correct.  you can't convert between any of the vector types.  the following
> > just does a straight copy, no conversion (nop):
> > 
> >   vector short b;
> >   vector int a = (vector int) b;
> 
> What about other operations, e.g. arithmetic?

not allowed. or perhaps undefined


> > 	vector int foo = ((vector int)(1,2,3,4));
> > 
> > this kinda sucks all together because i don't think gcc has vector constants
> > at all, do we?  we could pass it as a BLKmode or as a struct right?
> 
> I think you should just use the C99 compound literal syntax here (with

yes, ideally.  but what do we do for the current specs which specifies
parentheses?

aldy

Re: front end changes for altivec

[Joseph S. Myers]

On Mon, 26 Nov 2001, Aldy Hernandez wrote:

> __vector must be first among type specifiers.  the specs are rather skekchy,

That's not consistent with how other type specifiers work.  It would make
more sense for the list of possible type specifier combinations to include
such things as "__vector signed int" and any permutation thereof.

> ok, but how would we differentiate between the diff vector sizes.
> altivec has "vector int" being V4SI, but vector int could mean V2SI in
> mmx.  suggestion welcome while i think through this.

The answer from some quarters might be "vector int<4>" or "vector<4> int",
but this adds complications to the C grammar I don't really want there
since > can be part of a constant expression (so if going that way then do
as many as possible of defining disambiguating rules by reference to
existing practice, proving the existence or nonexistence of ambiguous
cases, describing how the parsing should be implemented).  Or use
"vector(4)".  Or add some other way of specifying a non-default vector
size.

> correct.  you can't convert between any of the vector types.  the following
> just does a straight copy, no conversion (nop):
> 
>   vector short b;
>   vector int a = (vector int) b;

What about other operations, e.g. arithmetic?

> 	vector int foo = ((vector int)(1,2,3,4));
> 
> this kinda sucks all together because i don't think gcc has vector constants
> at all, do we?  we could pass it as a BLKmode or as a struct right?

I think you should just use the C99 compound literal syntax here (with
braces, not parentheses).  Presumably the ABI says how such arguments are
passed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: front end changes for altivec

[Aldy Hernandez]

> >     __vector keyword:
> >     
> >     	__vector int	=> mode(V4SI)
> >     	__vector char	=> mode(V16QI)
> >     	etc etc
> 
> Precise rules?  Is __vector a type specifier that can be added to the
> various lists of keyword type specifiers that can be used?  Which of the
> type specifiers listed in C99 6.7.2#2 can it be used with?  I take it it

i believe it can only be used with signed, unsigned, int, short, float,
and char.  you can't use it with typedefs or enums.

> can't be used with typedefs, structs or unions.  Can it be used with

but they can be used as fields in a struct.

> enums?  Why those particular sizes of vectors rather than others?  Will
> __vector on its own imply __vector int?

__vector must be first among type specifiers.  the specs are rather skekchy,
but it seems like you need to specifically mention int.  you can also
have pointers to these types (vector int *).

> 
> Given proper answers, thorough documentation and testcases and a design of
> an architecture-independent __vector keyword that allows for the variety
> of vector types on different architectures, this is comparatively harmless

ok, but how would we differentiate between the diff vector sizes.
altivec has "vector int" being V4SI, but vector int could mean V2SI in
mmx.  suggestion welcome while i think through this.

> - as long as there are no implicit conversions between these types and any
> other type in either direction and no operations can be applied to these

correct.  you can't convert between any of the vector types.  the following
just does a straight copy, no conversion (nop):

  vector short b;
  vector int a = (vector int) b;

> types other than passing to and returning from functions, and any explicit
> conversions available are properly documented and justified.
> 
> >     vector constant initializers:
> >     
> >     	__vector int foo = (5, 8, 3, 2);
> >     
> >     (yes, those are parentheses, not curlys :-()
> 
> Obviously a bad idea - (5, 8, 3, 2) has a defined meaning that does not
> depend on the context here.  This is worse than was suggested in July
> (which was (vector float) (1.0, 2.0, 3.0, 4.0)) though that still ought to
> be a compound literal instead.

oh sorry, it has to be casted and it has to have an extra set of ()'s so
it might not be too bad:

	vector int foo = ((vector int)(1,2,3,4));

this kinda sucks all together because i don't think gcc has vector constants
at all, do we?  we could pass it as a BLKmode or as a struct right?

this might not be too bad if we come up with a mechanism for all simd 
processors.  i'm still wondering how to manage the diff sizes.

does this make it clearer?

aldy

Re: front end changes for altivec

[Joseph S. Myers]

On 26 Nov 2001, Aldy Hernandez wrote:

> the altivec specs require changes to the gcc front end.  this has been
> brought up before but no one has really commented.  now before everyone
> start raising shields and going "yuck, no way", hear me out.

You have of course read the previous thread on "Vector Extensions in GCC"  
from July.

>     __vector keyword:
>     
>     	__vector int	=> mode(V4SI)
>     	__vector char	=> mode(V16QI)
>     	etc etc

Precise rules?  Is __vector a type specifier that can be added to the
various lists of keyword type specifiers that can be used?  Which of the
type specifiers listed in C99 6.7.2#2 can it be used with?  I take it it
can't be used with typedefs, structs or unions.  Can it be used with
enums?  Why those particular sizes of vectors rather than others?  Will
__vector on its own imply __vector int?

Given proper answers, thorough documentation and testcases and a design of
an architecture-independent __vector keyword that allows for the variety
of vector types on different architectures, this is comparatively harmless
- as long as there are no implicit conversions between these types and any
other type in either direction and no operations can be applied to these
types other than passing to and returning from functions, and any explicit
conversions available are properly documented and justified.

>     vector constant initializers:
>     
>     	__vector int foo = (5, 8, 3, 2);
>     
>     (yes, those are parentheses, not curlys :-()

Obviously a bad idea - (5, 8, 3, 2) has a defined meaning that does not
depend on the context here.  This is worse than was suggested in July
(which was (vector float) (1.0, 2.0, 3.0, 4.0)) though that still ought to
be a compound literal instead.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: front end changes for altivec

[Andreas Jaeger]

Aldy Hernandez <aldyh@redhat.com> writes:

> hi guys!
>
> the altivec specs require changes to the gcc front end.  this has been
> brought up before but no one has really commented.  now before everyone
> start raising shields and going "yuck, no way", hear me out.
>
> i would really hate to perpetually maintain a set of front end patches,
> so i'm wondering if there's any sensible, least intrusive way to
> implement these changes and have them incorporated into mainline gcc.
>
> i am not a fan at all of these front end changes, but the specs are
> already out there and a variety of other compilers already conform to
> them.
>
> the changes are very few and are outlined below:
>
>     __vector keyword:
>     
>     	__vector int	=> mode(V4SI)
>     	__vector char	=> mode(V16QI)
>     	etc etc
>     	
>         (it could really be __altivec_vector for all i care because the
>         specs allow part of the definitions to be in a separate include
>         file (altivec.h?), so we could have
>         
>         #define __vector __altivec_vector
>         
> 	   ...in a separate file.
>     
>     vector constant initializers:
>     
>     	__vector int foo = (5, 8, 3, 2);
>     
>     (yes, those are parentheses, not curlys :-()
>     
> i'd first like to discuss the feasability of incorporating these changes
> with irritating the least amount of people, and having them accepted.
>
> failing this, i have a few thoughts on extending the lexical analyzer to
> include some sort of front end plugin support.-- but i'd like to discuss
> the previous option first.

How does this relate to Intel's SSE/SSE2?  Could the same frontend
used for all these SIMD extensions?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

front end changes for altivec

[Aldy Hernandez]

hi guys!

the altivec specs require changes to the gcc front end.  this has been
brought up before but no one has really commented.  now before everyone
start raising shields and going "yuck, no way", hear me out.

i would really hate to perpetually maintain a set of front end patches,
so i'm wondering if there's any sensible, least intrusive way to
implement these changes and have them incorporated into mainline gcc.

i am not a fan at all of these front end changes, but the specs are
already out there and a variety of other compilers already conform to
them.

the changes are very few and are outlined below:

    __vector keyword:
    
    	__vector int	=> mode(V4SI)
    	__vector char	=> mode(V16QI)
    	etc etc
    	
        (it could really be __altivec_vector for all i care because the
        specs allow part of the definitions to be in a separate include
        file (altivec.h?), so we could have
        
        #define __vector __altivec_vector
        
	   ...in a separate file.
    
    vector constant initializers:
    
    	__vector int foo = (5, 8, 3, 2);
    
    (yes, those are parentheses, not curlys :-()
    
i'd first like to discuss the feasability of incorporating these changes
with irritating the least amount of people, and having them accepted.

failing this, i have a few thoughts on extending the lexical analyzer to
include some sort of front end plugin support.-- but i'd like to discuss
the previous option first.

bomb away.

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Daniel Berlin]

On Thursday, November 29, 2001, at 02:16  AM, Richard Henderson wrote:

> On Thu, Nov 29, 2001 at 12:55:16AM -0500, Daniel Berlin wrote:
>> 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>))).
>
> Yes, that's lovely.  Now what about, say, saturating adds?
>
>
> r~
Anything that doesn't map easily onto rtl requires builtins.
--Dan

Re: front end changes for altivec

[Jack Lloyd]

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

Re: front end changes for altivec

[Richard Henderson]

On Thu, Nov 29, 2001 at 12:55:16AM -0500, Daniel Berlin wrote:
> 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>))).

Yes, that's lovely.  Now what about, say, saturating adds?


r~

Re: front end changes for altivec

[Daniel Berlin]

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

Re: front end changes for altivec

[Alexandre Oliva]

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

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: front end changes for altivec

[Per Bothner]

Alexandre Oliva 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 could still support implicit iteration over vector elements for
> operations such as copying, addition and subtraction, relieving the
> source code from the need to worry about the exact vector size, while
> still allowing code to pick into it somehow, for example:
> 
> vector int x[] = { 1, 2, 3, 4, 5, 6, 7 }; // probably pads with 0s
> 
> vector int y[7];
> 
> ...
> 
>   y = x;
>   y = x + y; 

My recommendation is to define the extension as syntactic sugar
for a C++ template.  That has the advantage of providing a clean definition.

There happens to be a standard C++ template that seems to closely
match what is needed:  valarray.  This was specifically designed
to be highly optimizable and to be mapped to vector hardware.

My preference:

* We provide hooks so that valarray implementations can run
optimized on suitable hardware, including Altivec and MMX.

* We encourage programmers who want to write efficient code
to use C++ and the valarray type.  They gain the benefits of
making their code both portable and fast.

* If we define a C "vector" extension we define in terms of
the C++ valarray type.  Specifically, there should be no
Altivec-target-dependent functionality or optimizations
that you can access from the C extension that you can't also
access using the valarray template in C++.  I want to encourage
people to write clean portable code, not some kludge.  A
pre-processor that translates from Alticvec C into valarray-using
C++ code would be my preference.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: front end changes for altivec

[Daniel Berlin]

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

Re: front end changes for altivec

[Alexandre Oliva]

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 could still support implicit iteration over vector elements for
operations such as copying, addition and subtraction, relieving the
source code from the need to worry about the exact vector size, while
still allowing code to pick into it somehow, for example:

vector int x[] = { 1, 2, 3, 4, 5, 6, 7 }; // probably pads with 0s

vector int y[7];

...

  y = x;
  y = x + y; 

I'm unsure whether indexing such an array (x[n]) would get you the nth
int or the nth vector element.  I'm inclined to prefer the latter,
even though it's a bit odd that you wouldn't be able to get x[6] on
the vector above unless the machine didn't support any int-type vector
mode, such that the int vector size is 1.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 07:26:34PM -0600, Aldy Hernandez wrote:
> > Modulo the varying size of "short",
> > 
> >   #define __vector  __attribute__((__vector_size__(16)))
> 
> the thing is that there are builtins that expect V4SI, or V4SF, or
> V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
> and cast them (which does nothing, but quiets the parser).

Examine the type that __vector is modifying ("short" for this example)
and you get HImode.  Divide vector_size(16) by sizeof(HImode) to yield 8.
Put it all together and to get V8HImode.  Voila.


r~

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 05:40:11PM -0800, Dale Johannesen wrote:
> I come from a BE background, so to me a single mode for all
> 16-byte vector objects seems cleanest, but I'm sure people from
> FE backgrounds would disagree.

This falls down for operations such as saturating addition --
you have to know what the element width is, so that you can
choose the proper instruction.


r~

Re: front end changes for altivec

[Dale Johannesen]

On Tuesday, November 27, 2001, at 05:26 PM, Aldy Hernandez wrote:
>
> the thing is that there are builtins that expect V4SI, or V4SF, or
> V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
> and cast them (which does nothing, but quiets the parser).
>
> actually, why can't we do this then:
>
> 	#define __vector  __attribute__ ((mode(V4SI)))
>
> i still would like to have different modes for different vector types
> (short, int, char).

I got this working both ways and eventually let all vectors be V16QI.
That removes some bloat in rs6000.md and there are somewhat fewer
changes in the target-independent parts of the code (e.g. for casts).
The other way is certainly more convenient for resolving those builtins,
though.  I come from a BE background, so to me a single mode for all
16-byte vector objects seems cleanest, but I'm sure people from
FE backgrounds would disagree.

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:01, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 06:52:55PM -0600, Aldy Hernandez wrote:
> > > How about __vector_size__(16) then?
> > 
> > can anyone think of any way to get:
> > 
> > 	vector int foo;		/* v4si */
> > 	vector short bar;	/* v2hi */
> > 	vector char hot;	/* v16qi */
> > 	etc
> > 
> > working for altivec in a target independent manner?
> 
> Modulo the varying size of "short",
> 
>   #define __vector  __attribute__((__vector_size__(16)))

the thing is that there are builtins that expect V4SI, or V4SF, or
V16QI, etc.  i guess i can have all vectors be V4SI (or vector_size(16))
and cast them (which does nothing, but quiets the parser).

actually, why can't we do this then:

	#define __vector  __attribute__ ((mode(V4SI)))

i still would like to have different modes for different vector types
(short, int, char).


> 
> works.  And char/short/int doesn't actually vary *that* widely.
> The targets for which these are not 1, 2 and 4 octets wide are
> fairly rare, so I'm willing to gloss over that.  Especially
> since you can also work around this like so:
> 
> 	#if SHRT_MAX == 32767
> 	typedef unsigned short u16;
> 	#elif INT_MAX == 32767
> 	typedef unsigned int u16;
> 	#else
> 	#error you're strange
> 	#endif
> 
> 	__vector u16 foo;
> 
> I think for stuff written for gcc itself we should encourage the use
> of mode(V4SI), or some other explicit element size + vector width
> syntax yet to be determined.
> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 07:12:31PM -0600, Aldy Hernandez wrote:
> > But what do you do with
> > 
> > 	vector int x = (vector int){ 1, 2, 3, 4 };
> > 
> > when a vector is only two elements wide?
> 
> that should trigger a syntax error.  and vector constants should only be
> used in initializers.

Then how do you initialize _any_ data across different simd
implementations?


r~

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 19:03, 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.

right

> But what do you do with
> 
> 	vector int x = (vector int){ 1, 2, 3, 4 };
> 
> when a vector is only two elements wide?

that should trigger a syntax error.  and vector constants should only be
used in initializers.
> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Richard Henderson]

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?


r~

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 06:52:55PM -0600, Aldy Hernandez wrote:
> > How about __vector_size__(16) then?
> 
> can anyone think of any way to get:
> 
> 	vector int foo;		/* v4si */
> 	vector short bar;	/* v2hi */
> 	vector char hot;	/* v16qi */
> 	etc
> 
> working for altivec in a target independent manner?

Modulo the varying size of "short",

  #define __vector  __attribute__((__vector_size__(16)))

works.  And char/short/int doesn't actually vary *that* widely.
The targets for which these are not 1, 2 and 4 octets wide are
fairly rare, so I'm willing to gloss over that.  Especially
since you can also work around this like so:

	#if SHRT_MAX == 32767
	typedef unsigned short u16;
	#elif INT_MAX == 32767
	typedef unsigned int u16;
	#else
	#error you're strange
	#endif

	__vector u16 foo;

I think for stuff written for gcc itself we should encourage the use
of mode(V4SI), or some other explicit element size + vector width
syntax yet to be determined.


r~

Re: front end changes for altivec

[Aldy Hernandez]

> 
> Except that I think this is much worse.  At least for "int" you
> have sizeof, INT_MAX, CHAR_BITS etc to determine the nature of
> the type on the machine.  I think we can do better for vectors.

why can't you have sizeof((vector int))?

> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 16:00, Richard Henderson wrote:
> On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> > not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> > "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> > to a given vector size because that depends on the type being vectored.
> 
> How about __vector_size__(16) then?
> 
> > and then have a default for the given backend+target_switches...
> 
> Absolutely not.  No machine dependant defaults.  You can't take
> that source to another machine.

can anyone think of any way to get:

	vector int foo;		/* v4si */
	vector short bar;	/* v2hi */
	vector char hot;	/* v16qi */
	etc

working for altivec in a target independent manner?

if not, it pretty much looks like we need separate non-fsf patches to
get this to work.

> 
> 
> r~
-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 02:50:22PM -0800, Stan Shebs wrote:
> > Absolutely not.  No machine dependant defaults.  You can't take
> > that source to another machine.
> 
> You mean like how we don't have machine-dependent sizes for int
> and long int?

Exactly!  All the world's a VAX!  ;-)  

Except that I think this is much worse.  At least for "int" you
have sizeof, INT_MAX, CHAR_BITS etc to determine the nature of
the type on the machine.  I think we can do better for vectors.


r~

Re: front end changes for altivec

[Stan Shebs]

Richard Henderson wrote:
> 
> On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> > not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> > "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> > to a given vector size because that depends on the type being vectored.
> 
> How about __vector_size__(16) then?
> 
> > and then have a default for the given backend+target_switches...
> 
> Absolutely not.  No machine dependant defaults.  You can't take
> that source to another machine.

You mean like how we don't have machine-dependent sizes for int
and long int?

:-)

Stan

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 03:54:42PM -0600, Aldy Hernandez wrote:
> not good, because we have "vector int" (V4SI), "vector short" (V8HI),
> "vector char" (V16QI), etc.  we can't just define "__vector" to expand
> to a given vector size because that depends on the type being vectored.

How about __vector_size__(16) then?

> and then have a default for the given backend+target_switches...

Absolutely not.  No machine dependant defaults.  You can't take
that source to another machine.


r~

Re: front end changes for altivec

[Aldy Hernandez]

> I prefer
> 
> 	int foo __attribute__((vector(4)));
> 
> which, iirc, also works as a prefix,
> 
> 	__attribute__((vector(4))) int foo;
> 
> which, with appropriate cpp magic in <altivec.h> becomes
> 
> #define __vector  __attribute__((__vector__(4)))
> 
> 	__vector int foo;

not good, because we have "vector int" (V4SI), "vector short" (V8HI),
"vector char" (V16QI), etc.  we can't just define "__vector" to expand
to a given vector size because that depends on the type being vectored.

i still prefer :):

	__vector(4) int foo;

and then have a default for the given backend+target_switches:

	__vector int foo;

a clean implementation IMO.

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Richard Henderson]

On Tue, Nov 27, 2001 at 09:24:03AM -0600, Aldy Hernandez wrote:
> do we really need to specify a vector size?

Yes.  This documents the intention of the author of the code.

With such, one could write generic code to handle the case that
the machine does not support SIMD at all, or that the machine
supports SIMD but in a narrower mode written in the source.

It also lets the author write code with larger vector sizes (8, 16, 32...)
and have the compiler automatically decompose into whatever the
machine can actually handle.  Which might possibly give the 
compiler more information and let it optimize better.  Dunno
for sure about that, but it's not implausable.

> 	vector(4) int foo;
> 	vector<4> int foo;

I prefer

	int foo __attribute__((vector(4)));

which, iirc, also works as a prefix,

	__attribute__((vector(4))) int foo;

which, with appropriate cpp magic in <altivec.h> becomes

#define __vector  __attribute__((__vector__(4)))

	__vector int foo;

which merely leaves you the c++ nastiness problem with
"vector" vs "__vector" vs "std::vector".


r~

Re: front end changes for altivec

[Aldy Hernandez]

> > > SSE is 128 bits.
> > 
> > sorry, mmx then.
> > 
> > which complicates things further... with this mmx and sse and sse2, what
> > would the default be for "vector int"?  mmx is 64bits (right?) and sse
> > is 128bits, so when we talk of vector int, what are we talking about.
> 
> I think all these problems show clearly that the extension is poorly thought
> out and should not be included in gcc.

that's why i brought up here first, so we can talk it through and
hopefully come up with a good design that can be used across all the
different simd architectures.

re the different sizes in x86 simd (mmx/sse/sse2), we could have the
default vector sizes depend on the macro i proposed.  the macro could
return different vector sizes based on TARGET_MMX/etc flags.  very
simple.

and if the user specifies:

	vector<2> int foo;

it can only mean V2SI in mmx if TARGET_MMX (and available) or V2SI in
sse* if TARGET_SSE* (and available).

i don't think it's that bad.

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Bernd Schmidt]

On 27 Nov 2001, Aldy Hernandez wrote:

> On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote:
> > Aldy Hernandez <aldyh@cygnus.com> writes:
> > 
> > >> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> > >> but this adds complications to the C grammar I don't really want there
> > >> since > can be part of a constant expression (so if going that way then do
> > >> as many as possible of defining disambiguating rules by reference to
> > >> existing practice, proving the existence or nonexistence of ambiguous
> > >> cases, describing how the parsing should be implemented).  Or use
> > >> "vector(4)".  Or add some other way of specifying a non-default vector
> > >
> > > i've thought about this some more.
> > >
> > > do we really need to specify a vector size?  simd architectures
> > > generally have a specific vector size, 64bits for sse* and 128bits for
> > > altivec.  
> > 
> > SSE is 128 bits.
> 
> sorry, mmx then.
> 
> which complicates things further... with this mmx and sse and sse2, what
> would the default be for "vector int"?  mmx is 64bits (right?) and sse
> is 128bits, so when we talk of vector int, what are we talking about.

I think all these problems show clearly that the extension is poorly thought
out and should not be included in gcc.


Bernd

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, 2001-11-27 at 09:50, Andreas Jaeger wrote:
> Aldy Hernandez <aldyh@cygnus.com> writes:
> 
> >> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> >> but this adds complications to the C grammar I don't really want there
> >> since > can be part of a constant expression (so if going that way then do
> >> as many as possible of defining disambiguating rules by reference to
> >> existing practice, proving the existence or nonexistence of ambiguous
> >> cases, describing how the parsing should be implemented).  Or use
> >> "vector(4)".  Or add some other way of specifying a non-default vector
> >
> > i've thought about this some more.
> >
> > do we really need to specify a vector size?  simd architectures
> > generally have a specific vector size, 64bits for sse* and 128bits for
> > altivec.  
> 
> SSE is 128 bits.

sorry, mmx then.

which complicates things further... with this mmx and sse and sse2, what
would the default be for "vector int"?  mmx is 64bits (right?) and sse
is 128bits, so when we talk of vector int, what are we talking about.

perhaps i should leave that to whomever adds the vector keyword stuff
for x86 :)

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.

Re: front end changes for altivec

[Andreas Jaeger]

Aldy Hernandez <aldyh@cygnus.com> writes:

>> The answer from some quarters might be "vector int<4>" or "vector<4> int",
>> but this adds complications to the C grammar I don't really want there
>> since > can be part of a constant expression (so if going that way then do
>> as many as possible of defining disambiguating rules by reference to
>> existing practice, proving the existence or nonexistence of ambiguous
>> cases, describing how the parsing should be implemented).  Or use
>> "vector(4)".  Or add some other way of specifying a non-default vector
>
> i've thought about this some more.
>
> do we really need to specify a vector size?  simd architectures
> generally have a specific vector size, 64bits for sse* and 128bits for
> altivec.  

SSE is 128 bits.

But I agree, we should find a general solution!

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: front end changes for altivec

[Aldy Hernandez]

> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> but this adds complications to the C grammar I don't really want there
> since > can be part of a constant expression (so if going that way then do
> as many as possible of defining disambiguating rules by reference to
> existing practice, proving the existence or nonexistence of ambiguous
> cases, describing how the parsing should be implemented).  Or use
> "vector(4)".  Or add some other way of specifying a non-default vector

i've thought about this some more.

do we really need to specify a vector size?  simd architectures
generally have a specific vector size, 64bits for sse* and 128bits for
altivec.  

so, "vector int x" in sse* means V2SI, provided ints are 32bits.

in altivec, "vector int" means V4SI, provided ints are 32bits.

so do we _really_ need to specify a size or can it be determined from
backend info?

if we really do need to specify vector size, then either of your
proposals will work:

	vector(4) int foo;
	vector<4> int foo;

(i really don't like "vector int<4> foo" :))

what do you suggest <> or ()?

furthermore, we need to have a default vector size for the altivec stuff
to work-- and it makes for prettier code :).  so:

	vector int foo	--> V4SI in altivec
	vector int foo	--> V2SI in SSE*
	etc

we would need defaults for vector + [int, short, bool, char, float]. 
for this, we could add a macro to gcc that given an SI/HI/QI/SF returns
an V4SI/V8HI/V18QI/V4SF.  this seems like the cleanest idea.

how does this sound?

aldy

Re: front end changes for altivec

[Richard Henderson]

On Mon, Nov 26, 2001 at 05:50:04PM -0800, Aldy Hernandez wrote:
> yes, ideally.  but what do we do for the current specs which specifies
> parentheses?

Ignore them.


r~

Re: front end changes for altivec

[Aldy Hernandez]

On Tue, Nov 27, 2001 at 01:04:05AM +0000, Joseph S. Myers wrote:
> On Mon, 26 Nov 2001, Aldy Hernandez wrote:
> 
> > __vector must be first among type specifiers.  the specs are rather skekchy,
> 
> That's not consistent with how other type specifiers work.  It would make
> more sense for the list of possible type specifier combinations to include
> such things as "__vector signed int" and any permutation thereof.

sure

> > ok, but how would we differentiate between the diff vector sizes.
> > altivec has "vector int" being V4SI, but vector int could mean V2SI in
> > mmx.  suggestion welcome while i think through this.
> 
> The answer from some quarters might be "vector int<4>" or "vector<4> int",
> but this adds complications to the C grammar I don't really want there

i don't link this idea.

> as many as possible of defining disambiguating rules by reference to
> existing practice, proving the existence or nonexistence of ambiguous
> cases, describing how the parsing should be implemented).  Or use

i'm not sure i follow., can you give an example.

> "vector(4)".  Or add some other way of specifying a non-default vector
> size.

that could be better. 
> 
> > correct.  you can't convert between any of the vector types.  the following
> > just does a straight copy, no conversion (nop):
> > 
> >   vector short b;
> >   vector int a = (vector int) b;
> 
> What about other operations, e.g. arithmetic?

not allowed. or perhaps undefined


> > 	vector int foo = ((vector int)(1,2,3,4));
> > 
> > this kinda sucks all together because i don't think gcc has vector constants
> > at all, do we?  we could pass it as a BLKmode or as a struct right?
> 
> I think you should just use the C99 compound literal syntax here (with

yes, ideally.  but what do we do for the current specs which specifies
parentheses?

aldy

Re: front end changes for altivec

[Joseph S. Myers]

On Mon, 26 Nov 2001, Aldy Hernandez wrote:

> __vector must be first among type specifiers.  the specs are rather skekchy,

That's not consistent with how other type specifiers work.  It would make
more sense for the list of possible type specifier combinations to include
such things as "__vector signed int" and any permutation thereof.

> ok, but how would we differentiate between the diff vector sizes.
> altivec has "vector int" being V4SI, but vector int could mean V2SI in
> mmx.  suggestion welcome while i think through this.

The answer from some quarters might be "vector int<4>" or "vector<4> int",
but this adds complications to the C grammar I don't really want there
since > can be part of a constant expression (so if going that way then do
as many as possible of defining disambiguating rules by reference to
existing practice, proving the existence or nonexistence of ambiguous
cases, describing how the parsing should be implemented).  Or use
"vector(4)".  Or add some other way of specifying a non-default vector
size.

> correct.  you can't convert between any of the vector types.  the following
> just does a straight copy, no conversion (nop):
> 
>   vector short b;
>   vector int a = (vector int) b;

What about other operations, e.g. arithmetic?

> 	vector int foo = ((vector int)(1,2,3,4));
> 
> this kinda sucks all together because i don't think gcc has vector constants
> at all, do we?  we could pass it as a BLKmode or as a struct right?

I think you should just use the C99 compound literal syntax here (with
braces, not parentheses).  Presumably the ABI says how such arguments are
passed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: front end changes for altivec

[Aldy Hernandez]

> >     __vector keyword:
> >     
> >     	__vector int	=> mode(V4SI)
> >     	__vector char	=> mode(V16QI)
> >     	etc etc
> 
> Precise rules?  Is __vector a type specifier that can be added to the
> various lists of keyword type specifiers that can be used?  Which of the
> type specifiers listed in C99 6.7.2#2 can it be used with?  I take it it

i believe it can only be used with signed, unsigned, int, short, float,
and char.  you can't use it with typedefs or enums.

> can't be used with typedefs, structs or unions.  Can it be used with

but they can be used as fields in a struct.

> enums?  Why those particular sizes of vectors rather than others?  Will
> __vector on its own imply __vector int?

__vector must be first among type specifiers.  the specs are rather skekchy,
but it seems like you need to specifically mention int.  you can also
have pointers to these types (vector int *).

> 
> Given proper answers, thorough documentation and testcases and a design of
> an architecture-independent __vector keyword that allows for the variety
> of vector types on different architectures, this is comparatively harmless

ok, but how would we differentiate between the diff vector sizes.
altivec has "vector int" being V4SI, but vector int could mean V2SI in
mmx.  suggestion welcome while i think through this.

> - as long as there are no implicit conversions between these types and any
> other type in either direction and no operations can be applied to these

correct.  you can't convert between any of the vector types.  the following
just does a straight copy, no conversion (nop):

  vector short b;
  vector int a = (vector int) b;

> types other than passing to and returning from functions, and any explicit
> conversions available are properly documented and justified.
> 
> >     vector constant initializers:
> >     
> >     	__vector int foo = (5, 8, 3, 2);
> >     
> >     (yes, those are parentheses, not curlys :-()
> 
> Obviously a bad idea - (5, 8, 3, 2) has a defined meaning that does not
> depend on the context here.  This is worse than was suggested in July
> (which was (vector float) (1.0, 2.0, 3.0, 4.0)) though that still ought to
> be a compound literal instead.

oh sorry, it has to be casted and it has to have an extra set of ()'s so
it might not be too bad:

	vector int foo = ((vector int)(1,2,3,4));

this kinda sucks all together because i don't think gcc has vector constants
at all, do we?  we could pass it as a BLKmode or as a struct right?

this might not be too bad if we come up with a mechanism for all simd 
processors.  i'm still wondering how to manage the diff sizes.

does this make it clearer?

aldy

Re: front end changes for altivec

[Joseph S. Myers]

On 26 Nov 2001, Aldy Hernandez wrote:

> the altivec specs require changes to the gcc front end.  this has been
> brought up before but no one has really commented.  now before everyone
> start raising shields and going "yuck, no way", hear me out.

You have of course read the previous thread on "Vector Extensions in GCC"  
from July.

>     __vector keyword:
>     
>     	__vector int	=> mode(V4SI)
>     	__vector char	=> mode(V16QI)
>     	etc etc

Precise rules?  Is __vector a type specifier that can be added to the
various lists of keyword type specifiers that can be used?  Which of the
type specifiers listed in C99 6.7.2#2 can it be used with?  I take it it
can't be used with typedefs, structs or unions.  Can it be used with
enums?  Why those particular sizes of vectors rather than others?  Will
__vector on its own imply __vector int?

Given proper answers, thorough documentation and testcases and a design of
an architecture-independent __vector keyword that allows for the variety
of vector types on different architectures, this is comparatively harmless
- as long as there are no implicit conversions between these types and any
other type in either direction and no operations can be applied to these
types other than passing to and returning from functions, and any explicit
conversions available are properly documented and justified.

>     vector constant initializers:
>     
>     	__vector int foo = (5, 8, 3, 2);
>     
>     (yes, those are parentheses, not curlys :-()

Obviously a bad idea - (5, 8, 3, 2) has a defined meaning that does not
depend on the context here.  This is worse than was suggested in July
(which was (vector float) (1.0, 2.0, 3.0, 4.0)) though that still ought to
be a compound literal instead.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: front end changes for altivec

[Andreas Jaeger]

Aldy Hernandez <aldyh@redhat.com> writes:

> hi guys!
>
> the altivec specs require changes to the gcc front end.  this has been
> brought up before but no one has really commented.  now before everyone
> start raising shields and going "yuck, no way", hear me out.
>
> i would really hate to perpetually maintain a set of front end patches,
> so i'm wondering if there's any sensible, least intrusive way to
> implement these changes and have them incorporated into mainline gcc.
>
> i am not a fan at all of these front end changes, but the specs are
> already out there and a variety of other compilers already conform to
> them.
>
> the changes are very few and are outlined below:
>
>     __vector keyword:
>     
>     	__vector int	=> mode(V4SI)
>     	__vector char	=> mode(V16QI)
>     	etc etc
>     	
>         (it could really be __altivec_vector for all i care because the
>         specs allow part of the definitions to be in a separate include
>         file (altivec.h?), so we could have
>         
>         #define __vector __altivec_vector
>         
> 	   ...in a separate file.
>     
>     vector constant initializers:
>     
>     	__vector int foo = (5, 8, 3, 2);
>     
>     (yes, those are parentheses, not curlys :-()
>     
> i'd first like to discuss the feasability of incorporating these changes
> with irritating the least amount of people, and having them accepted.
>
> failing this, i have a few thoughts on extending the lexical analyzer to
> include some sort of front end plugin support.-- but i'd like to discuss
> the previous option first.

How does this relate to Intel's SSE/SSE2?  Could the same frontend
used for all these SIMD extensions?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

front end changes for altivec

[Aldy Hernandez]

hi guys!

the altivec specs require changes to the gcc front end.  this has been
brought up before but no one has really commented.  now before everyone
start raising shields and going "yuck, no way", hear me out.

i would really hate to perpetually maintain a set of front end patches,
so i'm wondering if there's any sensible, least intrusive way to
implement these changes and have them incorporated into mainline gcc.

i am not a fan at all of these front end changes, but the specs are
already out there and a variety of other compilers already conform to
them.

the changes are very few and are outlined below:

    __vector keyword:
    
    	__vector int	=> mode(V4SI)
    	__vector char	=> mode(V16QI)
    	etc etc
    	
        (it could really be __altivec_vector for all i care because the
        specs allow part of the definitions to be in a separate include
        file (altivec.h?), so we could have
        
        #define __vector __altivec_vector
        
	   ...in a separate file.
    
    vector constant initializers:
    
    	__vector int foo = (5, 8, 3, 2);
    
    (yes, those are parentheses, not curlys :-()
    
i'd first like to discuss the feasability of incorporating these changes
with irritating the least amount of people, and having them accepted.

failing this, i have a few thoughts on extending the lexical analyzer to
include some sort of front end plugin support.-- but i'd like to discuss
the previous option first.

bomb away.

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.