Re: Removing unnecessary ADDR_EXPRs

[Daniel Berlin <dberlin at dberlin dot org>]

On Tue, 2005-05-17 at 10:25 -0600, Jeffrey A Law wrote:
> 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
> combiner:
> 
>   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.

pool allocate, then blow away pools.  If you decide you like the tree,
you throw it in gc memory.

PRE has pools for almost every type of expression nowadays, because it
has to create "value number expressions for all of them".  (these are
the same expressions with the operands replaced with the value handles)

This is also PRE ends up doing during phi_translate, etc, and it doesn't
seem to cause speed loss even though it means you memcpy the tree twice
if you decide you like it (to put it back into gc memory).  We've never
had memory problems for PRE doing this, even on very large testcases,
where it's creating hundreds of thousands of value number statements.

Heck, i can even make subpools work if it would help.

It's either pools or obstacks for garbage. You really aren't going to be
able to do much better unless we make the zone collector the default
(then you could throw all of this stuff in it's own zone that is always
trashed).

> 
>   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).

Same here.  Pass it a bunch of temporary pools.