This is the mail archive of the
mailing list for the GCC project.
Re: front end changes for altivec
> 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
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
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*
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?