From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16081 invoked by alias); 23 Dec 2004 17:22:21 -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 16044 invoked by alias); 23 Dec 2004 17:22:17 -0000 Date: Thu, 23 Dec 2004 17:22:00 -0000 Message-ID: <20041223172217.16043.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-12/txt/msg03366.txt.bz2 List-Id: ------- Additional Comments From law at redhat dot com 2004-12-23 17:22 ------- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Thu, 2004-12-23 at 13:31 +0000, steven at gcc dot gnu dot org wrote: > ------- Additional Comments From steven at gcc dot gnu dot org 2004-12-23 13:31 ------- > Jeff, as I said, you're attacking problems not related to the original > problem reported in this PR. Maybe you don't use bugzilla often enough > to see how annoying it is when the PR summary and the problem described > in the bug report don't match. But oh well, whatever, if you can win > 10% here, why am I complaining ;-) The bug report really should have been called "compilation speed regression" rather than calling out "jump threading" -- a goodly number of the changes necessary to get 15524 to a point of almost acceptable were not jump threading related. How about this, open a new report with the same testcase and a generic description about compile-time regression, then close 15524. Seems like a make-work project, but hey, if it makes you happy.... > I'm very curious about your tree alias rewrite. Got a plan/overview of > it somewhere? In simplest terms, we lose the braindamaged type memory tag nonsense and only do type based alias analysis on objects that have not been disambiguated by other means. This as the effect of greatly reducing number of type based aliasing checks -- which accounts for the vast majority of the compilation time for 15855. > Is it GCC 4.0 material? Unsure, mostly because I will not have much time to work on it for the next 3 weeks. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524