This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[tree-ssa] RFC: Making control flow more explicit
- From: Diego Novillo <dnovillo at redhat dot com>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 06 Aug 2003 17:37:57 -0400
- Subject: [tree-ssa] RFC: Making control flow more explicit
- Organization: Red Hat Canada
Lately, I've been toying with the idea of making the control flow more
explicit, something which has popped up every now and then. Currently,
we have a few problems with the tree IL having things that are hidden
from the optimizers and make us do more work (e.g., code insertion).
I have the beginnings of a patch that exposes a few things that I think
might be useful. I'd like opinions and whether people think that this
would indeed make things easier.
The initial idea involves no IL changes. I think that we need to make
changes to the physical structure of the IL, but in my prototype I'm
just using what we have now:
COND_EXPR
---------
Instead of having:
if (cond)
then_clause;
else
else_clause;
we would have
if (cond)
goto then_lab;
goto else_lab;
then_lab:
then_clause;
goto endif_lab;
else_lab:
else_clause;
endif_lab:
LOOP_EXPR
---------
Instead of having
while (1)
{
if (cond)
goto loop_end;
body;
}
we would have
goto loop_test;
loop_top:
body
loop_test:
if (cond)
goto loop_end;
goto loop_top;
loop_end:
SWITCH_EXPR
-----------
This one I'm undecided. The easiest is to generate a decision tree, but
we may also want to generate a jump table. For now, I was thinking on
doing a decision tree with if's. I mainly want to prevent the
optimizers from having to deal with SWITCH_EXPR which has been a source
of some problems.
switch (var)
{
case 1:
body1;
goto out;
case 2:
body2;
goto out;
default:
bodyN;
}
out:
would be converted into
if (var == 1)
goto body1_lab;
if (var == 2)
goto body2_lab;
goto bodyN_lab;
body1_lab:
body1:
goto out;
body2_lab:
body2;
goto out;
bodyN_lab:
bodyN;
out:
I still have not thought about CATCH_EXPR, EH_FILTER_EXPR,
TRY_CATCH_EXPR and TRY_FINALLY_EXPR. Also, I find BIND_EXPR a bit
annoying, but I guess we need to respect scoping :)
Thoughts? I may be able to produce a working prototype in a few days.
I also don't know what effect this will have on the RTL expander,
whether it will help or make things worse. It should help us simplify
some of the code in the optimizers, at least.
Diego.