Re: Vector Extensions in GCC

[Stan Shebs <shebs at apple dot com>]

Michael Eager wrote:
> 
> On a more practical basis, making vector a reserved word causes
> problems.  'vector' is used in existing programs and is a defined
> template class in STL.  Programs using this vector keyword could
> not be compiled by any other standard-conforming C compiler.  As long
> as you don't mind breaking existing correct programs, being incompatible
> with C++, and discarding literally decades of effort to make C/C++
> a language in which you can write programs which are portable
> from one machine to another, then I guess this isn't a problem. ;-)

I didn't want to get into syntax, but since you mention it, the
implementation makes "vector" (and "__vector") context-sensitive,
and only turned on with -faltivec, so the impact of the keyword
isn't as bad as one might think.

> As you mention, this is an allocation issue.  My view is that
> compilers should handle allocation of data to machine resources
> rather than having the user attempt to do this.  The only place where
> C/C++ attempts to have the user handle allocation (i.e., the register
> keyword) it turns out to range from superflous to pointless.

An interesting analogy.  Once upon a time the register keyword
*was* important, for particular compilers with weak or nonexistent
register allocation algorithms.  Certainly autovectorization would
make language changes much less compelling, but we don't seem very
close to that.

> > Now, the questions.  First, what is the right way to do explicit
> > vector operations in GCC?  Should it be done with additional user
> > visible types, or via attributes on existing types like float[4]?
> 
> Don't do explicit vector operations in C.
> 
> Architectures change, and explicit operations tie your code to one
> particular architecture and one particular version.  What may work
> well for today's implementation may not work well on tomorrow's
> processor with more and longer vector registers.

People that actually work at this level are OK with the nonportability.
They've already determined the performance characteristics of their
code, and that they can do things by hand better than any compiler
available.  There aren't very many of these developers, but their work
tends to have a great influence on what machines users buy - the
speed of MPEG encoding, image convolving, and so forth translate
pretty directly into sales.  The developers would be writing assembly
code if they couldn't get compiler support, but then they would be
struggling with pipeline issues that the compiler already handles
well enough.

> My appologies if this is rather more philosophical than a practical
> comment about how to go about implementing this in GCC.

That's OK, that's the kind of insight I was hoping for.  Basically
I'm stuck between two opposing camps - one says "we must have these
vector extensions in GCC, no debate allowed" and the other says
"vector extensions are evil, don't let them in".  The way to resolve
this kind of impasse is to pick apart the positions and look for
points of agreement.  For instance, AltiVec programmers are mainly
focussed on getting optimal throughput, and I believe they would
be willing to change syntaxes if that got them better results.

Stan