Stepanov, PowerPC, life_analysis

[Mark Mitchell <mark at codesourcery dot com>]

I've figured out why are Stepanov abstraction numbers (which basically
exercise ADDRESSOF in different ways) are worse on PowerPC than they
were for GCC 2.95.

The bottom line is that GCC 2.95 got lucky.  (There are simple
transformations to the source that will cause us to generate lousy
code with 2.95 as well.)

  In the code stream for 3.0, after CSE, we end up with:

  (insn 206 11 229 (set (reg:SI 126)
	  (addressof:SI (reg/v:SI 83) 82 0x403464e0)) 282 {*movsi_internal1} (nil)
      (nil))

  (insn 229 206 210 (set (reg/s/v/f:SI 91)
	  (reg:SI 126)) -1 (nil)
      (nil))

  ...

  (insn 82 80 85 (set (reg/v/f:SI 106)
        (reg/s/v/f:SI 91)) 282 {*movsi_internal1} (nil)
    (nil))

  ...

  (insn 35 223 43 (set (reg/s/v/f:SI 91)
          (reg/v/f:SI 106)) 282 {*movsi_internal1} (nil)
      (expr_list:REG_EQUAL (addressof:SI (reg/v:SI 83) 82 0x403464e0)
          (nil)))

The important thing to notice is that all of these instructions are
dead: nothing here actually does anything, and these are the uses of
the REGs mentioned.

In 2.95, we had the first instruction, but not all of the other ones.
This is partly due to an artifact of the tree-based inliner, which
generates a few more register->register copies to express argument
passing, and partly perhaps due to changes in CSE.  

In any case, in 2.95, delete_trivially_dead_insns blows away the
equivalent of insn 206 and in 3.0 it doesn't because the instruction
is dead, but not trivially dead.

We purge_addressof after this point -- and the existence of insn 206
causes us to dump register 83 to the stack, and that's the performance
lossage.

This really points up how important it is to rework our global
optimizers to not commit to code shape up front.  The real solution
here is to keep ADDRESSOF until much later in the compilation, or some
such.  However, we're not going to do that now.

So, what can we do?  Well, the following patch (untested except on
this test case) fixes the problem by blowing away the silly register
copies before purging ADDRESSOF.  I don't know whether the basic-block
graph is in good shape at this point; the call to find_basic_blocks
may not be necessary.  And, I don't know if there's are other flags
that we should pass to life_analysis at this point.

But, I think this is the right approach.  And, I don't see what the
point in having delete_trivially_dead_insns around is when we have
this much better hammer -- we could probably eliminate the call to
that as well.

In any case, I'm looking for input as to people think that:

  - This is the right idea, and if so, whether the details are
    right.

  - Whether or not we need to fix this for GCC 3.0.

In the meantime, I'll run tests on i686-pc-linux-gnu to validate.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com