Re: [tree-ssa] RFC: Making control flow more explicit

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > > > Can you elaborate?  Those comments Zdenek made Last week's about the
> > > > tree IR seem to make sense.  Is it part of your eventual plan to get rid
> > > > of control expressions in the statement chain and represent control flow
> > > > with only the CFG (and insert code after going out of ssa)?  Or is it
> > > > just making control flow more explicit with more GOTO_EXPRs?  (Just that
> > > > would also help in some cases I've seen in the past few days)
> > > > 
> > > For now, I just want to make control flow more explicit.  But, as I
> > > mentioned, I would like us to change the physical representation of the
> > > IR to simplify statement chaining and get rid of its container nature. 

This is basically it:

> > > The flowgraph-is-the-IR view might well be what we end up with.  But I'd
> > > like to get there by natural progression.  There is a lot of
> > > infrastructure to change to get to that extreme.

I agree it is radical and great change.  But it has to be.  I cannot see
how could you get to it in "natural progression" -- the changes you
propose in this thread form about 20 lines of the patch that I am
currently working on (that will unfortunately have about 10000).
But if we want to change the IR, there somewhere must be a step of this
magnitude (simply because basically whole tree-cfg.c is IR-specific),
and IMHO the sooner the better.

> > I am now almost done with the cfg-based representation.  The things seem
> > to work, I have just a few misscompilations in the testsuite just now
> > that I should solve today or tomorrow.  Could you please wait with the
> > changes you propose till then?  The patch will be quite complicated
> > as it is, without conflicts with changes leading basically to the same
> > goal.
> 
> Can you show us how you're going to do things? Ie. are you constructing
> the CFG from GIMPLE and dumping redundant tree nodes with control
> expressions, or are you keeping them around somewhere?

I remove the "invisible" constructs and replace them with chain of
statements that are kept in basic blocks; more precisely

COMPOUND_EXPR -- removed
LOOP_EXPR -- replaced with goto
COND_EXPR, SWITCH_EXPR -- may only be present at the end of basic block
  and their branches must only contain simple GOTO_EXPRs
BIND_EXPRs, EH constructs -- there is more fun with these.  It would be
  too difficult to handle them now in other way than to recreate them
  after optimizations.  So I keep a tree of these constructs separately
  (plus pointers to their entry and exit blocks) and after optimizations
  I reconstruct the trees from them.

The patch so far would have somewhat drastic consequences:
1) I had to remove most of the cleanups in tree-cfg.c
2) Since LOOP_EXPRs are killed, there are no loop notes emitted and
   loop optimized does nothing.
I would like to first push the IR change in, then to handle them, in
order not to make the patches even more complicated. 1) should be
trivial (most of cleanups should be adaptable, I have discussed with
Honza about that even parts of rtl cfgcleanup could be reused.
2) is easy too, as there are at least three ways of handling it
    -- I may recreate the loop notes using the natural loops discovery
    -- I may handle LOOP_EXPRs the same way BIND_EXPRs are
    -- I also have a loop optimizer that does not need them :-)

Zdenek