Re: front end changes for altivec

[Aldy Hernandez <aldyh at cygnus dot com>]

> 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