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,
> > 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).
> >
> You will have to break that out into independent pieces.
This is going to be a problem, as I have no idea how. If someones
provide me with some idea of such small changes, I will be happy to.
> There is more
> than one problem here. Changing something like the way statements are
> chained is orthogonal to exposing more control flow, for instance.
Yes, but as I said what you call "exposing more control flow" is change
on 20 lines that basically does not move you towards the goal.
> Exposing more control flow allow us more liberty when doing certain
> transformations. Modifying the way statements are chained is purely a
> compile time performance issue.
No it is not. In the current way of "chaining" many trivial cfg
transformations are fairly complicated (I would say impossible, but you
somehow managed to do some of them. While I admire it, I also regret
you haven't spent your time on making the things easier to do instead).
> Both need to be tested and incorporated separately.
No problem, but the second patch would still have the same size.
> > The patch so far would have somewhat drastic consequences:
> > 1) I had to remove most of the cleanups in tree-cfg.c
> >
> This is precisely why we are doing evolutionary changes. This, for
> instance, is unacceptable.
But neccesary. In the moment you remove the underlying trees, nothing
of them has a slightest chance to work.
> The goal in these three months is to beat
> mainline. We cannot accept regressions of this nature. Particulary if
> these are changes that have been sitting in your local tree with almost
> no exposure.
Ok, agreed.
> We could, however, move this to a sub-branch of tree-ssa to serve as a
> staging branch for doing some of the more radical stuff you have in
> mind. We could move from that branch into tree-ssa, as they become more
> stable.
This seems like the only plausible way to me just now. Unless we come
up with something better, I will probably do this.
Zdenek