This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]