This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Removing unnecessary ADDR_EXPRs

This is an adaptation of some old code from Andrew Pinski to eliminate
ADDR_EXPR expressions.  

I really want this to be done with a tree combiner, but there's some
interesting issues we need to resolve before we can really write a tree

  1. Need a way to tell of a particular statement is gimple or not -- 
     deep checking of the entire statement, not the superficial stuff
     we do right now.

  2. A memory efficient means to change trees, and undo those changes
     if necessary.

  3. A memory efficient means (which works in combination with #1 and
     #2) which allows us to combine multiple statements, gimplify the
     result, then compare how many statements appear in the gimplified
     result vs the number of statements we combined (ie, so that we can
     do things like 3->2 or 4->3 combinations).

The problem with tree combination is more of memory efficiency than
anything -- it can get ugly rather fast.  I've played with a variety
of things, but haven't come up with anything I like yet.

In the mean time, we've got a ton of useless crud in our IL because we
can't propagate non-constant ADDR_EXPR expressions to their use sites
(which are usually INDIRECT_REFs or PLUS_EXPR for pointer arithmetic).

Andrew posted some code way back in Sept which allows us to propagate
ADDR_EXPRs.  He built it as a separate pass, but it fits into our
existing forward propagation pass reasonably well.  This code handles
the cases Andrew's code did as well as a few more.  In all we see
several thousands of ADDR_EXPRs propagated bootstrapping the compiler
(not including the runtime system).  The most common propagations 
are into INDIRECT_REF nodes (which removes the ADDR_EXPR and
INDIRECT_REF).  We also propagate into PLUS_EXPR which recovers
array indexing from pointer arithmetic.

One rather surprising result is the compiler is actually slightly
faster -- I had expected it to get slightly slower as we have to
walk over every statement in the forward propagator rather than
just peeking at the last statement.  I'm not sure if that's because
we have fewer statements, fewer vops or some other secondary
effect.  I just know I like it :-)

Bootstrapped and regression tested on i686-pc-linux-gnu.  Fixes new
testcases in the testsuite (of course).

Attachment: PPP
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]