Re: Status of vector-extension infrastructure

[Richard Henderson <rth at cygnus dot com>]

On Thu, Aug 24, 2000 at 06:33:44PM +0100, Thomas Womack wrote:
> Though, if you're going the builtin-functions route and if you've
> implemented the necessary background work to have a whole new type
> of register, I can't see it being *that* much more trouble to have
> the same built-in functions happen to generate Altivec code if I
> compile the code on a G4.

Yeah, well, except that the work was paid for by Intel, and they
wanted us to implement Intel's defined set of intrinsics, which is
pretty much a 1-1 by name correspondance with the SSE1 insns.
You do, however, get the same set of intrinsics that VC++ uses,
so I guess that's something, interoperability-wise.

Doing this in a properly machine-independant way would require a
bit more care in picking which intrinsics to define and what they
mean.  Which is hard once you leave the relm of parallel saturating
adds and the like.  Invariably you'll leave some weird thing out
that one processor defines, forcing the user to go back to assembly
anyway.  That's not to say that we couldn't do some common subset
and leave the rest to machine-specific intrinsics, but we havn't.

> I'm exactly the other way round: auto-vectorisation would be nice, but I'd
> much rather have the language extensions; I'd much rather ship source with
> 'compile gcc-3.14.1, then compile this with it' on the label...

What I'm hearing is that you don't want to program in C, you want to
program in something else that makes it easier to write vector code.

Fair enough, but that would indicate to me that you ought to be
looking at using some other language besides C instead of wanting
to change C to be something it isn't.  And whether you knew it or
not, the blue sky extensions you describe are in Fortran 95.


r~