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