Re: front end changes for altivec

[Andreas Jaeger <aj at suse dot de>]

Aldy Hernandez <aldyh@redhat.com> writes:

> 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.

How does this relate to Intel's SSE/SSE2?  Could the same frontend
used for all these SIMD extensions?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj