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

[Diego Novillo <dnovillo at redhat dot com>]

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.