Re: [PATCH, RFC] Expose target addressing modes before expand

[Richard Guenther <rguenther at suse dot de>]

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