Re: [tree-ssa] RFC: Making control flow more explicit

[Diego Novillo <dnovillo at redhat dot com>]

On Mon, 2003-08-11 at 10:59, law@redhat.com wrote:
> In message <1060536473.27906.48.camel@frodo.toronto.redhat.com>, Diego Novillo 
> writes:
>  >On Sat, 2003-08-09 at 13:43, Zdenek Dvorak wrote:
>  >
>  >> 1) elimination of LOOP_EXPRs [500] -- a few lines in gimplification, remova
>  >l
>  >>    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.
> Why would an earlier pass care about LOOP_EXPRs?
> 
I was going to point out something like source code analysis, but even
that is not a good reason.  LOOP_EXPRs are not representative of source
code loops.  So, I withdraw the objection.

However, if we are going to do this at the gimplifier then we need to
consider whether we want GIMPLE itself be an IL with no control
structures other than COND_EXPRs and GOTO_EXPRs.

>From an optimization point of view I see very little value in keeping
LOOP_EXPR and SWITCH_EXPRs, for instance.  But without evidence to the
contrary, I had thought that as a first cut we should probably start by
dropping them in a post-gimplification pass.  We can always remove them
from GIMPLE altogether if we find no other use for them.  I don't think
we'll find them useful, though.

Zdenek, how much work would it be to clean up your patches that deal
with LOOP_EXPRs, COND_EXPRs and SWITCH_EXPRs?  I'm particularly
interested in LOOP_EXPRs.  For SWITCH_EXPRs, I think going to a
multi-way branch is probably the easiest solution.  That means using the
label vector collected in the SWITCH_EXPR and converting those into real
LABEL_DECLs.


Diego.