This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 21 Dec 2004 06:23:38 -0000
- Subject: [Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
- References: <20040518194300.15524.pinskia@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From law at redhat dot com 2004-12-21 06:23 -------
Subject: Re: [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases
On Mon, 2004-12-20 at 00:51 +0000, steven at gcc dot gnu dot org wrote:
> ------- Additional Comments From steven at gcc dot gnu dot org 2004-12-20 00:51 -------
> I suggest we close this one, 9% is just comparable to the overall
> slowdown we see in pretty much all code. This is just noise in
> the list of regressions. If nobody objects, I'll close this in a
> couple of days from now...
I wouldn't close it. There's still some significant representational
issues that need addressing (jump vectors in RTL). It exposes some
major lamness in invariant code motion (trying to hoist a few thousand
instances of GLOBAL_VAR), and some lameness in our CFG code as well
(the edge cache).
The fact that we're spending so much time redirecting edges at the RTL
level is also an indication that we may not be passing off optimal
trees to the expanders.
In all, there may be another 10% gain for pr15524 waiting for us to
nail down.
These are all issues I want to see examined, but they're lower priority
than fixing the extreme lameness in our aliasing code which is causing
even bigger compile-time regressions in other testcodes.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524