PATCH [mainline] rewrite of altivec.h to improve cpp performance

Joseph S. Myers jsm@polyomino.org.uk
Fri Sep 10 17:19:00 GMT 2004


On Fri, 10 Sep 2004, Fariborz Jahanian wrote:

> Attached test case shows a serious performance deficiency in macros 
> defined for the c-language in altivec.h to handle Altivec library calls. 
> A non-trivial altivec call whose arguments are one or more altivec 
> calls, take the cpp into a tail-spin with eventual heap exhaustion. I 
> have rewritten many of the macros to avoid abundant nested use of the 
> __builtin_choose_expr. I have not done this for all the macros. I have 
> done this for the ones which showed up in customer code, as well as 
> those which experience this problem the most (and could be easily 
> modified). This patch is bootstrapped and dejagnu tested for 
> apple-ppc-dawin.

There have been some proposed patches to add a target hook to facilitate 
overloaded built-in functions.  I think that's the only way to address the 
underlying problem rather than just some of the symptoms in some cases. 
(But if you don't want to make such a bigger change, addressing the 
symptoms is itself a useful improvement.)

http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00791.html
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00820.html

Given that the changes to target-independent code are small and the 
enormous macro expansions that are inevitable when the macros have 
expansions that contain any parameter name more than once are clearly a 
bug, I'd think such a change would be reasonable at the present 
development stage.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)



More information about the Gcc-patches mailing list