This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] RFC: Making control flow more explicit
> > 1) elimination of LOOP_EXPRs  -- a few lines in gimplification, removal
> > of references to them in tree-*, plus loop note regeneration just
> > before loop header copying
> Why would you need removing them from the gimplifier? The exposure of
> more control flow should not need changes in the gimplifier. Earlier
> passes may want to deal with LOOP_EXPRs.
because it is the point where it is easy and from performance reasons I
did not want to traverse the tree unnecessarily. Of course it may also
be done the way it is done in the big ugly patch of mine, i.e. just
directly before creating cfg if you prefer.
> > 2) lowering of SWITCH_EXPRs and COND_EXPRs (so that their branches are
> > just gotos) [500-1000] -- a change to gimplification, cleanup + a few changes in
> > optimizers
> Again, same question.
The same answer :-)
> > 3) replacing COMPOUND_EXPRs with double-linked chain of statements [500-1000] --
> > mostly changes to block iterators + places in code that rely on the
> > fact that the whole function tree is kept, and final pass that
> > regenerates COMPOUND_EXPRs
> Regenerate COMPOUND_EXPRs? What for?
I really don't want to rewrite expr.c now. It should be done
eventually because of compile performance reasons, but I would wait
with it until the other changes are in place and stabilized.
> > 4) moving BIND_EXPRs and exception handling constructs to their own tree 
> > probably the most complicated step; some changes to iterators, many
> > to cleanup, final pass to move structures back. This is basically
> > equivalent to the core of my current patch, I will try to think more
> > on how to make this step less painful.
> What is this change? I'm not sure I understand what you are doing here.
After previous three steps, these will be the only high-level constructs
left in the tree. I don't know how to get rid of them easily, so unless
someone proposes better solution, I just keep them separate from the
rest of the statements (so that they do not create problems a la bugs in
removal of unreachable blocks) and put them back after we are done with cfg
> > 5) rewrite of make_edges  -- especially eh edges are created in a
> > weird way currently, IMHO.
> Re-write to improve compile-time, create fewer edges, or what?
Mostly to improve compile-time.
> > Is this acceptable? It will of course be a great lot of patches, so I
> > won't go into it unless I know that someone is ready to take the burden
> > of reviewing them.
> In principle, yes. I'm interested in your changes to expose control
> flow. However, they shouldn't happen too early. Let's go through the
> changes one by one. We need to discuss the design decisions you made,
> and what you are trying to accomplish with each one. For the more
> radical changes, perhaps we ought to create a sub-branch so that you can
> continue with the experimental changes until they're more stable.