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
- From: law at redhat dot com
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Diego Novillo <dnovillo at redhat dot com>, Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 11 Aug 2003 09:06:25 -0600
- Subject: Re: [tree-ssa] RFC: Making control flow more explicit
- Reply-to: law at redhat dot com
In message <20030809174318.GA31964@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
>Hello,
>
>I have spent a few hours thinking about the issue and I now think there
>might be a way to split the patch into smaller ones (perhaps also not
>seeing the code for a day helped :-). The proposed splitting (numbers
>in brackets mean my estimate on size of the change):
Good. Conceptually, you can break things down by dealing with each of
the control structures individually. Ie, kill LOOP_EXPRs, then
SWITCH_EXPRs, then COND_EXPRs, etc etc.
>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
Yup. This one should be relatively easy. In fact, I suspect you'll
end up removing more code than you write :-)
>2) lowering of SWITCH_EXPRs and COND_EXPRs (so that their branches are
> just gotos) [500-1000] -- a change to gimplification, cleanup + a few chan
>ges in optimizers
I'd recommed splitting this up into two different hunks as well. One
which deals with SWITCH_EXPRs, the other which deals with COND_EXPRs. Note
you want to make sure that whatever you do with COND_EXPRs doesn't regress
the code we present to the RTL optimizers -- we're actually at a point
where we typically present the RTL optimizers with *fewer* jumps than
without gimplification -- largely by being smarter about not creating
silly jumps.
>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
I've always wanted double-chaining and removal of the COMPOUND_EXPR wrappers
so no arguments from me.
>4) moving BIND_EXPRs and exception handling constructs to their own tree [200
>0]
> 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.
This is going to be bloody ugly. I'd postpone this until last :-)
>5) rewrite of make_edges [1000] -- especially eh edges are created in a
> weird way currently, IMHO.
The plan has always been to lower TRY_FINALLY into TRY_CATCH, we just
haven't gotten around to it yet.
jeff