This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
front end changes for altivec
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Date: 26 Nov 2001 04:53:20 -0600
- Subject: front end changes for altivec
hi guys!
the altivec specs require changes to the gcc front end. this has been
brought up before but no one has really commented. now before everyone
start raising shields and going "yuck, no way", hear me out.
i would really hate to perpetually maintain a set of front end patches,
so i'm wondering if there's any sensible, least intrusive way to
implement these changes and have them incorporated into mainline gcc.
i am not a fan at all of these front end changes, but the specs are
already out there and a variety of other compilers already conform to
them.
the changes are very few and are outlined below:
__vector keyword:
__vector int => mode(V4SI)
__vector char => mode(V16QI)
etc etc
(it could really be __altivec_vector for all i care because the
specs allow part of the definitions to be in a separate include
file (altivec.h?), so we could have
#define __vector __altivec_vector
...in a separate file.
vector constant initializers:
__vector int foo = (5, 8, 3, 2);
(yes, those are parentheses, not curlys :-()
i'd first like to discuss the feasability of incorporating these changes
with irritating the least amount of people, and having them accepted.
failing this, i have a few thoughts on extending the lexical analyzer to
include some sort of front end plugin support.-- but i'd like to discuss
the previous option first.
bomb away.
--
Aldy Hernandez E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.