From mboxrd@z Thu Jan 1 00:00:00 1970 From: mike stump To: gcc@gcc.gnu.org, zlaski@apple.com Cc: aldyh@redhat.com, jsm28@cam.ac.uk Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Date: Mon, 26 Nov 2001 19:52:00 -0000 Message-ID: <200111270351.TAA17242@kankakee.wrs.com> X-SW-Source: 2001-11/msg01321.html Message-ID: <20011126195200.FZMLRVcAs1orP1mL0GrvZGj1vmU2naqyJ468drKv7RI@z> > Date: Mon, 26 Nov 2001 18:26:45 -0800 > From: Ziemowit Laski > 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.