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

[Zdenek Dvorak]

Hello,

> Op do 07-08-2003, om 23:27 schreef Zdenek Dvorak:
> > 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 agree that it would be nice to do it now instead of months (years?)
> from now.  But the thing is, tree-ssa _has_ to be ready for 3.5 (it was
> decided that 3.5 would not ship without this), so you better be sure
> that your ideas work and it doesn't create a huge slowdown or other
> niceness...  :-)

There still is some time (three months if I count well, not counting with 
any delays); I am sure I can fix any problems that I cause in that time.

> What about the optimizers?  I hope they do not need major reworks again?

No, except for the cfg cleanup I mention below.  There are some minor
changes, but nothing important.

> > > > 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
> 
> How do you chain statements then?

Double linked chain of containers.

> And what happened to tree/block statement iterators?  You said you don't
> like them,

I don't like the purpose for that block statement iterators were created
and their internals; otherwise I like the idea.

> but I think most of us do.  Do they still work, or have you
> got a replacement for it?  (Fingers crossed: double linked chain? ;-)

They of course still work; I haven't touched tree statement iterators, block ones
just run on the chains.

> > LOOP_EXPR -- replaced with goto
> 
> Makes sense.
> 
> 
> > COND_EXPR, SWITCH_EXPR -- may only be present at the end of basic block
> >   and their branches must only contain simple GOTO_EXPRs
> 
> Makes a lot of sense.
> 
> 
> Looks like you're implementing what Diego suggested yesterday, only in a
> far more radical way.
> 
> 
> > 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.
> 
> If you're not handling BIND_EXPRs, how are you dealing with scopes,
> then?

the way I described -- they are peeled for optimizations, then put again
back in their original places.  I don't think it is much different from
what was done with them previously (except that they sitted directly in
trees).

> > 2) Since LOOP_EXPRs are killed, there are no loop notes emitted and
> >    loop optimized does nothing.
> 
> ... which should be fixed when you merge your new loop optimizer, right?
> 
> 
> Hmm, how are you going to compare the performance of your reworker
> compiler with the existing code, if you don't even have loop
> optimizations?

-fno-loop-optimize? But unfortunately even it won't pass, as there are
the missing cleanups that will probably damage the code.  So no, I
cannot do any reasonable performance comparisons until these pieces are
done, and I don't want to make the patch even more complicated by
doing them before the change is in.  Sounds like a problem :-(

Zdenek