This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] RFC: Making control flow more explicit
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