From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9022 invoked by alias); 1 Nov 2004 14:09:28 -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 8995 invoked by alias); 1 Nov 2004 14:09:24 -0000 Date: Mon, 01 Nov 2004 14:09:00 -0000 Message-ID: <20041101140924.8994.qmail@sourceware.org> From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040518194300.15524.pinskia@gcc.gnu.org> References: <20040518194300.15524.pinskia@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases X-Bugzilla-Reason: CC X-SW-Source: 2004-11/txt/msg00149.txt.bz2 List-Id: ------- Additional Comments From law at redhat dot com 2004-11-01 14:09 ------- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Mon, 2004-11-01 at 05:16 +0000, pinskia at gcc dot gnu dot org wrote: > ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-01 05:16 ------- > We are still way behind 3.3, it takes 15 seconds on my 1.5GHz PPC 7400 with 3.3 but with 4.0, well for > 4.0 time just look at Jeff's data and see that we are way behind still. Well, I haven't looked at 3.3, but I can make a reasonable guess that we're still way way way behind due to the way we update case labels when forwarding edges and splitting critical edges. Some early experiments I've done with that indicate there's another 30-35% improvement that can be made by fixing that problem. Then there's *another* 30% or so we're burning in the RTL branch prediction code (I haven't looked to see if there's anything we can do with that code yet). I doubt it makes much sense to look closely at 3.3 vs 4.0 for this testcase and similar code until we fix those glaring problems. It's also not clear to me how much of an improvement those changes will make in real-world code. ie, we could easily run into a case where we drastically improve that testcase without improving any real code, much like what happened recently with my changes to improve how we find/record equivalences for edges. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524