This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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


> > > 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?

And what happened to tree/block statement iterators?  You said you don't
like them, but I think most of us do.  Do they still work, or have you
got a replacement for it?  (Fingers crossed: double linked chain? ;-)


> 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 patch so far would have somewhat drastic consequences:
> 1) I had to remove most of the cleanups in tree-cfg.c

They are easy to rewrite if your new IR is in.  The old ones aren't all
that great anyway.


> 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?

Gr.
Steven


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]