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

[Daniel Berlin]

On Sunday, August 10, 2003, at 1:27 PM, Diego Novillo wrote:

> On Sat, 2003-08-09 at 13:43, Zdenek Dvorak wrote:
>
>> 1) elimination of LOOP_EXPRs [500] -- a few lines in gimplification, 
>> removal
>>    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.
>
>> 2) lowering of SWITCH_EXPRs and COND_EXPRs (so that their branches are
>>    just gotos) [500-1000] -- a change to gimplification, cleanup + a 
>> few changes in
>>    optimizers
>>
> Again, same question.
>
>> 3) replacing COMPOUND_EXPRs with double-linked chain of statements 
>> [500-1000] --
>>    mostly changes to block iterators + places in code that rely on the
>>    fact that the whole function tree is kept, and final pass that
>>    regenerates COMPOUND_EXPRs
>>
> Regenerate COMPOUND_EXPRs?  What for?
>
>> 4) moving BIND_EXPRs and exception handling constructs to their own 
>> tree [2000]
>>    probably the most complicated step; some changes to iterators, many
>>    to cleanup, final pass to move structures back.  This is basically
>>    equivalent to the core of my current patch, I will try to think 
>> more
>>    on how to make this step less painful.
>>
> What is this change?  I'm not sure I understand what you are doing 
> here.
>
>> 5) rewrite of make_edges [1000] -- especially eh edges are created in 
>> a
>>    weird way currently, IMHO.
>>
> Re-write to improve compile-time, create fewer edges, or what?
>
>
>> Is this acceptable? It will of course be a great lot of patches, so I
>> won't go into it unless I know that someone is ready to take the 
>> burden
>> of reviewing them.
>>
> In principle, yes.  I'm interested in your changes to expose control
> flow.  However, they shouldn't happen too early.  Let's go through the
> changes one by one.  We need to discuss the design decisions you made,
> and what you are trying to accomplish with each one.  For the more
> radical changes, perhaps we ought to create a sub-branch so that you 
> can
> continue with the experimental changes until they're more stable.

Just as a note about stability, his patches pass all but 2 regression 
tests, and
build and run all of SPEC with no problems (other than the gcc 
miscompares we get anyway).
They also do not regress the SPEC numbers.
They actually improve them on my system by a noticeable amount (2-5%).
Not that I think they shouldn't be split up or broken up and discussed. 
But they do work, and they appear relatively stable, especially 
compared to other changes that go on on the branch, so i would be in 
favor of them once they are split up properly and the 2 remaining 
regressions are fixed.

SPECFP base on  the C programs without his changes :

    177.mesa          1400   173       808
    179.art           2600   428       607
    183.equake        1300   142       917
    188.ammp          2200   554       397


With his changes:
177.mesa          1400   171       820
179.art           2600   419       620
183.equake        1300   138       944
188.ammp          2200   540       407


SPECINT shows similar numbers.
They are consistent over 3 seperate runs
Same flags and everything in both cases of course (-mtune=pentium4 -O2)