From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14030 invoked by alias); 19 Jan 2004 17:46:22 -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 13998 invoked from network); 19 Jan 2004 17:46:21 -0000 Received: from unknown (HELO www.eyesopen.COM) (12.96.199.11) by sources.redhat.com with SMTP; 19 Jan 2004 17:46:21 -0000 Received: from localhost (roger@localhost) by www.eyesopen.COM (8.11.6/8.11.6) with ESMTP id i0JGxUA24576 for ; Mon, 19 Jan 2004 09:59:31 -0700 Date: Mon, 19 Jan 2004 17:46:00 -0000 From: Roger Sayle To: gcc@gcc.gnu.org Subject: Compilation-time suggestion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-01/txt/msg01311.txt.bz2 I have a proposal/suggestion for perhaps improving GCC compilation time: Perhaps we could make more use of __builtin_expect inside the compiler itself. I'm not sure how much it would save us, but Jan's experiments with profiled bootstraps seemed to be encouraging, if memory serves. Certainly, SPEC results are much more competative with profiling enabled. If our profiling tools could be used to identify a small number of critial conditionals in the source code level, they could be annotated with __builtin_expect. Hopefully, this might be able to gain us much of the benefit of profile-feedback statically, assuming that its a few hotspots are responsible for a significant fraction of the gain. The usual use of macros in system.h can be used to allow the source code to bootstrap on non-GCC compilers. In addition to the tools locating critical conditionals at the source code level, we'd also need the ability to identify those __builtin_expect annotations that were incorrect or no longer critical, to prevent too much obfuscation of the source code. But certainly, machine generated functions such as the garbage collector's traversals and insn-recog could be made expectation aware. Clearly, there are issues with training sets, and branch probabilities that differ between one platform and another, but the hypothesis is that a handfull, perhaps 100, __builtin_expect annotations might give us a few percentage points, but maybe more. Are the benefits of user-annotated branch predictions significant enough to make them worth going after? Do any of the distributions come with a profile-optimized GCC? Just throwing out a brain-storm to see if anyone has a better handle on the potential benefits vs. increased maintenance overheads. Roger --