From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13150 invoked by alias); 9 Apr 2003 22:13:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13140 invoked from network); 9 Apr 2003 22:13:39 -0000 Received: from unknown (HELO Angel.zoy.org) (12.210.238.170) by sources.redhat.com with SMTP; 9 Apr 2003 22:13:39 -0000 Received: by Angel.zoy.org (Postfix, from userid 1000) id DD590B84B; Wed, 9 Apr 2003 15:13:37 -0700 (PDT) Date: Wed, 09 Apr 2003 22:55:00 -0000 From: Michel LESPINASSE To: Aldy Hernandez Cc: gcc@gcc.gnu.org Subject: Re: altivec support in gcc Message-ID: <20030409221337.GA29531@zoy.org> References: <20030408085330.GC20370@zoy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-SW-Source: 2003-04/txt/msg00398.txt.bz2 Hi Aldy, On Wed, Apr 09, 2003 at 09:15:42AM -0700, Aldy Hernandez wrote: > > First, is there any reason why altivec.h defines the second argument > > in vec_ld as being a vector pointer instead of a const vector pointer ? > > This is causing me no ends of trouble. > > Why is this causing you trouble? Well, this is nothing that I could not work around, but if I passed a const vector pointer gcc would complain that vec_ld discards the const modifier (dont remember the exact wording, but its the message you get when you pass a const pointer to a function that just takes a regular pointer, and gcc warns that function might write into your supposedly const data). In the context of vec_ld, the warning is stupid since vec_ld does NOT write into the data, and gcc should know it I think. Anyway - I had to add an explicit cast for the second argument of each vec_ld, just to keep gcc happy. In that regard, gnu gcc is not compatible with the old apple altivec-patched gcc. In the end, because I did not want to change all my vec_ld calls, I defined a my_vec_ld function with the cast, and then I used the preprocessor to replace all the vec_ld's with my_vec_ld. Like this: static inline vector_u8_t my_vec_ld (int const A, const uint8_t * const B) { return vec_ld (A, (uint8_t *)B); } #undef vec_ld #define vec_ld my_vec_ld This is ugly but it solved my problem :) I understand you can not do this in altivec.h though, because my version is limited by the fact it will only work on unsigned char vectors. > You need to split the last two assignments as you have discovered. If > you want to see why, compile with -save-temps and look at the > preprocessed output (the .i file). Yes. I looked at altivec.h and I understood what the issue is - it has to do all these weird convolutions to emulate function overloading, and as each argument gets expanded more than once this leads to exponential explosion. Still from a user point of view, this does look a bit silly - I can write expressions like out = a & b & c & d; and this works with any mix of integer types for a, b, c and d, and thanks god I don't have to split up a small expression like that - the compiler just figures it out. As a user, I would expect to be able to do the same things with vector types. Trying to understand what the difference is from gcc's point of view, I see that '&' is an operator, while vec_and internally relies on a builtin function, and that builtin functions are more limited as they dont support overloading, while C operators do. I dont know if it would be possible to somehow make gcc know about new operators for altivec ? that way vec_and(a,b) could be defined as something like ((a) __altivec_operator_and (b)) and __altivec_operator_and would be some operator, similar to &, which can take various types as input. I'm probably talking way out of my league here though. Once again, I used functions and preprocessor tricks to get rid of the exponential explosion issue, by taking advantage of the fact I only needed unsigned char vector versions of vec_and and vec_avg: #ifndef COFFEE_BREAK /* Workarounds for gcc suckage */ static inline vector_u8_t my_vec_and (vector_u8_t const A, vector_u8_t const B) { return vec_and (A, B); } #undef vec_and #define vec_and my_vec_and static inline vector_u8_t my_vec_avg (vector_u8_t const A, vector_u8_t const B) { return vec_avg (A, B); } #undef vec_avg #define vec_avg my_vec_avg #endif This is ugly but it does the trick for me - and frankly I did not want to break up all my expressions using temporaries if that makes them unreadable. I'm not sure what a good solution would be here. For starters, if altivec.h exported some non-overloaded versions of these functions, that might help a little - for example vec_and would be the overloaded version and vec_and_u8, vec_and_u16, vec_and_float, ... would be the non overloaded versions... I'm not sure if its doable as apple's altivec spec does not define these non overloaded versions though. > All the altivec functions in C get expanded into a disgusting set of > macros. These macros expand exponentially when you use them to call > themselves. This is not likely to change until the C front end has > overloaded functions, and we have no need for the macros. hmmm is there actually any plan for implementing overloaded functions in the C front end ? Not that I'd push for this thing (I dont think we want to make C look too much like C++) but it might be useful, at least for builtins, so gcc can better support the altivec intrinsics and stuff. Thanks, -- Michel "Walken" LESPINASSE "In this time of war against Osama bin Laden and the oppressive Taliban regime, we are thankful that OUR leader isn't the spoiled son of a powerful politician from a wealthy oil family who is supported by religious fundamentalists, operates through clandestine organizations, has no respect for the democratic electoral process, bombs innocents, and uses war to deny people their civil liberties." --The Boondocks