Re: Target-specific Front-Ends? (Was: front end changes for altivec)

[mike stump <mrs@windriver.com>]

> Date: Mon, 26 Nov 2001 18:26:45 -0800
> From: Ziemowit Laski <zlaski@apple.com>

> But this brings up a more general question, one that I've been
> meaning to ask of the wider community for quite some time: Should we
> come up with a generalized architecture in GCC (for all front-ends)
> to enable front-end extensions:

For the purposes you want it for, I propose we put this off into the
future as far as we can, with a little luck, we never do it.

> AltiVec is merely one example of an idiosyncratic extension that
> exists on only a small fraction of targets that GCC supports.  It
> would be nice to only enable the extension for the targets that need
> it

What would be nice, is to come up with language independent, machine
independent semantics that are nice, and provide them to the
frontends, and encourage the front ends to allow/expose them to the
user, in a MI way, since they are after all, MI.  We then use the
existing standard practice, if well designed, and we like it, to form
the basis of some future addition to the C/C++ language standard.  I
mean, they have MUL-ADD defined in the C99 standard (see fma in the
library), they certainly can add vector stuff.

Imagine a valarray of floats specialization in the C++ library that
uses vector float[8] internally, and feeds the += member functions to
the vector float[8] += gcc backend support code.  Just use valarray in
the natural way, and presto, the code uses a dual pipelined float[4]
hardware vector unit.  All the transformations to accomplish this
would be trivial enough (certainly easier than trying to intuit vector
usage in normal code.

Compile on a platform that doesn't have such hardware, the compiler
generates 8 calls to float +, as normal.  Maybe we want to expose the
maximal useful vec size, MATH_VEC_MAX_SIZE...  We might need to expose
the existence of particular operations.  Maybe...

By offering a MI way to do this, users can write their code in a
fairly portable way, and gain the benefits of such a standard.

The failings of the backend now, are, if the insn isn't supported by
the CPU, it doesn't work and the backend doesn't actually have any
operations, just a few types.  The failings of C/C++ languages are, we
need a standardized header to get at the operations, with standardized
names (not __builtin_addv4si), we might need a better syntax.  We need
to document all of the operations, and all operations always have to
work.  And we need to use these features in valarray.  We need to push
the standard out to the real folks that use these types of units, and
refine what we have to match what they need.