This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, RFC] Expose target addressing modes before expand
- From: Richard Guenther <rguenther at suse dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: "William J. Schmidt" <wschmidt at linux dot vnet dot ibm dot com>, gcc-patches at gcc dot gnu dot org, steven at gcc dot gnu dot org, dje at gcc dot gnu dot org, rguenth at gcc dot gnu dot org, bergner at gcc dot gnu dot org, pthaugen at gcc dot gnu dot org
- Date: Mon, 7 Feb 2011 17:33:05 +0100 (CET)
- Subject: Re: [PATCH, RFC] Expose target addressing modes before expand
- References: <1296856964.3135.25.camel@gnopaine> <4D501B2C.2040802@redhat.com>
On Mon, 7 Feb 2011, Jeff Law wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/04/11 15:02, William J. Schmidt wrote:
> > Problem report 46556 (http://gcc.gnu.org/PR46556) identifies a code-size
> > regression for powerpc targets. The root of the problem is changes in
> > address canonicalization a couple of years back. Discussion in the PR
> > suggests some form of exposure of target addressing modes prior to the
> > expand phase. Steven Bosscher (CCed) suggested this be done in a late
> > GIMPLE pass, using logic similar to what IVopts does for loops.
> >
> > Following is an early prototype of such a pass. I've verified that it
> > restores the regressed code to its earlier, more compact form, and most
> > of the addressing sequences on powerpc appear to be better or the same
> > as before. There are at least some complex expressions where early
> > exposure produces worse code in the form of extra multiplies; I have
> > some ideas for how to tune that down so the shift-add machinery for
> > multiplies isn't derailed. There are still 16 test cases that regress
> > on rev 169834 for powerpc, and I haven't examined other targets yet.
> > Clearly this is not yet ready, but before investing time into further
> > refinement, I'd like to get commentary on the general approach, as well
> > as any specific concerns. Please bear in mind that I am new to GCC, so
> > I'm still familiarizing myself with the infrastructure and am likely to
> > miss some things that are obvious to the initiated...
> >
> > The general approach is to rely on existing machinery used by
> > tree-ssa-loop-ivopts.c, simplifying out the parts that have to do with
> > induction variable optimizations. The new logic is pretty simple, but
> > the interactions with later phases may not be. For now, I've placed the
> > new pass in passes.c as the last -O1 tree-ssa pass.
> >
> > In addition to general comments, I'd be interested in answers to some
> > specific questions:
> >
> > 1) Are there concerns with early exposure of target addressing nodes on
> > other targets? Should the pass be gated to only operate on a subset of
> > targets?
> > 2) Is the pass placement appropriate?
> > 3) Have I missed any necessary fix-ups after modifying the GIMPLE code?
> >
> > Thanks very much for your insights!
> I haven't looked at the patch, but I will note my one major concern here
> is the increased exposure of target characteristics into gimple.
>
> One of the major problems we were trying to solve with gimple was the
> inability of seasoned developers to predict how a change to the
> optimizers would affect not just the target the developer was working
> on, but all the other targets the GCC project cares about.
>
> Gimple makes this problem a lot easier to deal with because most of the
> target dependencies don't show up until we lower into RTL (yes, there
> are exceptions, of course). The net result is developers can reasonably
> predict how their change will affect the resulting gimple across a wide
> range of platforms (we still have trouble predicting how the RTL will be
> affected obviously).
>
>
> Your patch takes gimple in a different direction and my concern is that
> 5-10 years from now we'll have the same problem we had with RTL all over
> again in gimple.
>
> So I'd like to see several of the seasoned developers chime in with
> their thoughts on this issue.
I think we agreed on (on some of the last GCC Summits) to move work
from the RTL pipeline up to a lowered GIMPLE (with some target
specifics). Eventually the goal of some people was to run register
allocation when we're still in GIMPLE SSA form.
The main concern I have with the lowering process is that we currently
leak the lowered form into generic SSA optimizers via IPA inlining,
thus defining a point in the pass pipeline where we "lower" GIMPLE
further is not possible right now.
I want to address that concern (for 4.7) by doing IPA inlining
of function bodies that are in state before our loop optimizers,
and having that as a good point where target specific information
leaks into the IL anyway (considering vectorization, IV optimization,
prefetching, ...).
I also plan to lower bitfield component references (and classical
bit-field-refs) to read-modify-write instruction sequences. That
will introduce other target dependencies considering alignment
and word sizes.
Thus, I am not concerned about target dependent stuff too much
as long as statements do not become invalid but merely sub-optimal
for a target, at least up to a definite point in the pass pipeline.
Richard.
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex