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


On Sat, 2003-08-09 at 13:43, Zdenek Dvorak wrote:

> 1) elimination of LOOP_EXPRs [500] -- 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.

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

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

> 4) moving BIND_EXPRs and exception handling constructs to their own tree [2000]
>    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.

> 5) rewrite of make_edges [1000] -- especially eh edges are created in a
>    weird way currently, IMHO.
>
Re-write to improve compile-time, create fewer edges, or what?


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


Diego.


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