Re: [ast-optimizer-branch] Simplification of Simple grammar

[Jan Hubicka <jh at suse dot cz>]

> > Actually, we lose valuable information if we simplify the grammar any
> > further.  The main example that comes to mind are FOR loops.  Once you
> > convert them to an IF/DO_WHILE combination, you lost the original
> > semantics and things get ugly for things like loop parallelization.
> > 
> Agree. 
> I will keep the transformations for the 3 loop structures as already 
> implemented for the goto/break elimination.  In this case I will only need
> the switch elimination to be applied before eliminating GOTO_STMTs. 

Just note that code that will "higher" loops to well behaved FOR loops
(like fortran DO loops do have) with iteration counter going from 0 to end
would help a lot to the new loop unrolling code on cfg-branch, so we will
not need to do so dificult analysis as old loop unrolling does.

Honza
> 
> > My suggestion is that for GOTO elimination, you create another pass to
> > further simplify the control structure into low-SIMPLE.  I would rather
> > do things in phases.  Some analyses and/or transformations might be
> > better done in high-SIMPLE.
> > 
> > After all, the grammar for low-SIMPLE that you're proposing is a strict
> > subset of high-SIMPLE.  The RTL conversion does not need to change. 
> > Furthermore, doing this in phases will give us better control when we
> > start testing transformations.  We have to watch out for code bloat and
> > increased compilation times.  It's easier to calibrate things when
> > dealing with lego-like modules instead of one monstruous black-box.
> > 
> 
> Right.
> 
> What about modules like :
> - switch_to_if
> - for_to_do
> - while_to_do
> 
> These functions can be called separately on passes that need a special form 
> of the Simple grammar.
> 
> 
> Seb.