From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8625 invoked by alias); 6 Apr 2005 19:21:37 -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 8485 invoked by uid 48); 6 Apr 2005 19:21:31 -0000 Date: Wed, 06 Apr 2005 19:21:00 -0000 Message-ID: <20050406192131.8484.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/msg00696.txt.bz2 List-Id: ------- Additional Comments From law at redhat dot com 2005-04-06 19:21 ------- More info. It appears that threading one specific jump is responsible for triggering the big speedup. And it could cause the kind of effects we're seeing. Basically we're threading a conditional branch to a loop exit test back to the top of the loop. This has the effect of creating nested loops. This in turn causes the register allocators to make different choices in regards to what values should be kept in registers and which end up on the stack (and at what offsets each object appears on the stack). That could cause the kind of decrease in L2 activity I'm seeing, particularly with the recursive nature of the function in question. I've got a few more tests to run before I claim this to be the cause of the huge improvement. But this is the best theory which fits the data I've seen so far. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794