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


Op wo 06-08-2003, om 23:37 schreef Diego Novillo:
> 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:

Can you elaborate?  Those comments Zdenek made Last week's about the
tree IR seem to make sense.  Is it part of your eventual plan to get rid
of control expressions in the statement chain and represent control flow
with only the CFG (and insert code after going out of ssa)?  Or is it
just making control flow more explicit with more GOTO_EXPRs?  (Just that
would also help in some cases I've seen in the past few days)

> COND_EXPR
> ---------

This looks especially good if we represent those `goto's with just edges ;-)

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

<dumb look> Why switch the order of the condition and the body?
What is wrong with just:

	loop_top:
	if (cond)
	  goto loop_end;
	body
	goto loop_top;
	loop_end:

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

While you're working at this:  It would be nice to have LABEL_EXPRs go
away from the statement chain.  Labels are not expressions, they're
addresses, and since labels always the first "statements" in a basic
block leaders, a chain of labels in a basic block always represent the
same address.  So why not attach something like a varray of LABEL_DECLs
to a basic block and remove them from the statements chain.  Right now
they're just in the way.

Gr.
Steven


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