[tree-ssa-branch]: Boolean propagation

[Daniel Berlin]

On Mon, 5 Aug 2002, Diego Novillo wrote:

> On Mon, 05 Aug 2002, Daniel Berlin wrote:
> 
> > My actual question is "should i bother to put this in a seperate file, and 
> > if so, what to name it".
> >
> tree-optimize.c is the place I had thought for these minor
> transformations.  Other cleanups like canonicalization of for
> loops or coalescing of control structures could also go in there.
> Don't worry too much about having to include c-* files.  This
> will change when we shuffle the tree codes around at a later
> date.

Okeydokey.

> 
> 
> > Do we forsee more trivial SIMPLE specific optimizations? 
> >
> I think so.  Yes.
> 
> > As a side note, one could easily use the results of value-range 
> > propagation to do this, but probably not be able to implement it  in 80 
> > lines of code. 
> > :)
> >
> Well, yes.  In the meantime, since it's such a trivial cleanup
> you feel free to put it in tree-optimize.c.  Schedule it before
> CCP.

I intended for it to run (in it's current form) before SSA.  This is so we 
don't have to handle creating new defs/updating stuff for the assignments 
it adds at the moment.
It's only SIMPLE specific, nothing in it needs or uses SSA.
Though it does use the CFG and varrefs, just not SSA chains.

So, I currently have it doing :

optimize_tree:
....
<create the cfg> 
<find varrefs>
<bool prop>
<destroy the cfg>
....
build ssa (which rebuilds the flowgraph, etc)
etc

where stuff in <'s> is new.

I've done this under the assumptions
1. We will eventually have helper routines to update SSA info for inserted 
statements. 
2.  That it's much cheaper to rebuild the flow graph, and refind varrefs, 
than it is to redo SSA.
3. That the cost of rebuilding the flow graph and refinding varrefs is 
cheap enough that it's not an issue right now.


If you think any of these are wrong, i'll make it update SSA chains/refs, 
but it'll take me a few days at least.

I wrote this thing in about 30 minutes, when i was bored waiting for a 
bootstrap to finish.

> BTW, you could generalize it a bit more by also considering 
> predicates of the form 'if (var == value)'.

If you just mean to include equality comparisons in addition to not-equal comparisons,  i've already 
done that. :)

 > 
> In any case, if we end up writing some other pass that
> generalizes this one, we can always get rid of it.
Assuming there aren't other advantages to doing bool-prop only (speed, 
fer instance).
out the > 
> 
> Diego.
> 
>