From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26475 invoked by alias); 22 Apr 2005 18:30:15 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 26437 invoked by uid 48); 22 Apr 2005 18:30:11 -0000 Date: Fri, 22 Apr 2005 18:30:00 -0000 Message-ID: <20050422183011.26435.qmail@sourceware.org> From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050206175258.19794.kazu@cs.umass.edu> References: <20050206175258.19794.kazu@cs.umass.edu> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/19794] [meta-bug] Jump threading related bugs X-Bugzilla-Reason: CC X-SW-Source: 2005-04/txt/msg03165.txt.bz2 List-Id: ------- Additional Comments From law at redhat dot com 2005-04-22 18:30 ------- The reload bug has been "resolved" or at least it's in a state where we can move forward with the jump threading changes. I've finally got the dynamic branching data which shows pretty much what I expected -- we execute fewer jumps :-) What I've done is used GCC's arc-profiling and branch prediction support to give us a picture of the runtime branching behavior of a set of programs (SPECINT2000). Specifically we're looking at how many conditional branches were executed (regardless of whether or not they were taken or not taken). We measure this with and without the jump threading changes. This gives us a highly accurate measure of how effective the jump threading changes are at reduncing the number of branches a program executes at runtime (it does not measure the secondary effects like exposing new expression redundancies). For SPECINT2000 we see a reduction in conditional branches of 4%. Yes, the threading changes manage to eliminate 4 out of every 100 branches executed at runtime across a fairly large benchmark suite. One benchmark (gzip) saw an incredible 21% reduction in runtime branches executed, though sadly gzip doesn't show a measurable runtime improvement (most likely because there were few, if any secondary optimization opportunities exposed by jump threading and/or the branches it eliminated were easily predicted by the hardware and thus weren't causing considerable branch mis-prediction penalties). These changes are also now showing a net improvement in compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794