This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH [mainline] rewrite of altivec.h to improve cpp performance
- From: "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- To: Fariborz Jahanian <fjahanian at apple dot com>
- Cc: "gcc-patches at gcc dot gnu dot org Patches" <gcc-patches at gcc dot gnu dot org>, Aldy Hernandez <aldyh at redhat dot com>
- Date: Fri, 10 Sep 2004 16:24:52 +0000 (UTC)
- Subject: Re: PATCH [mainline] rewrite of altivec.h to improve cpp performance
- References: <657BB687-0342-11D9-B49F-000A95BA54A6@apple.com>
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)