This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 31 Jan 2005 21:35:52 -0000
- Subject: [Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
- References: <20050131123257.19721.steven@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From law at redhat dot com 2005-01-31 21:35 -------
Subject: Re: [meta-bug] optimizations that CSE still
catches
On Mon, 2005-01-31 at 20:14 +0000, stevenb at suse dot de wrote:
> ------- Additional Comments From stevenb at suse dot de 2005-01-31 20:14 -------
> Subject: Re: [meta-bug] optimizations that CSE still catches
>
> My numbers for not disabling CSE completely but disabling path following
> are a lot less pessimistic. This was on an AMD Opteron at 1600MHz:
Right. That's what I'd focus on first -- that's what I was looking
at when I realized eons ago when I realized that if we don't do a good
job at jump threading, then we have little hope of ever drastically
simplifying CSE. I've been stuck in jump threading hell ever since :-)
Note I would _STRONGLY_ recommend people look at more than just the
compiler when evaluating the old CSE code. In particular it is
important that we look at things like 64bit arithmetic on 32bit
hosts (which happens often in kernels, but not nearly as often
in user level benchmarks).
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721