This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Disable old loop optimizer
- From: Jeffrey A Law <law at redhat dot com>
- To: Steven Bosscher <stevenb at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org, Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, Mark Mitchell <mark at codesourcery dot com>, Daniel Berlin <dberlin at dberlin dot org>
- Date: Wed, 13 Apr 2005 08:41:57 -0600
- Subject: Re: [patch] Disable old loop optimizer
- Organization: Red Hat, Inc
- References: <20050331212322.GA17354@atrey.karlin.mff.cuni.cz> <425C8868.6070403@codesourcery.com> <20050413085733.GA26367@atrey.karlin.mff.cuni.cz> <200504131232.51077.stevenb@suse.de>
- Reply-to: law at redhat dot com
On Wed, 2005-04-13 at 12:32 +0200, Steven Bosscher wrote:
>
> > 2) loop reversal
> [snip]
> > the major
> > problem is to decide when it is really useful.
>
> Are there any papers that discuss this?
If there are, I'd expect them to be bloody old.
The code in question was designed to allow us to take advantage of two
architecture features that allowed such loops to run faster:
1. On vaxes, m68ks, HPPA and a few other architectures, there was a
special decrement + compare to zero and branch instruction. dbCC
insns were usually faster than two separate instructions and in
some cases *much* faster (m68010 branching backwards 2 instructions
for example).
2. Even if the architecture didn't have a decrement-and-branch
instruction it was often slightly faster to test a value against
zero rather than an arbitrary constant or register.
The problem (of course) is that these transformations can be done
quite a bit easier in the tree world (just look at the contortions
we do in loop.c for this stuff, ick), but the costing models assume
we'll know something about the backend.
jeff