This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] RFC: Making control flow more explicit
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  -- a few lines in gimplification,
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 areAgain, same question.
just gotos) [500-1000] -- a change to gimplification, cleanup + a
few changes in
3) replacing COMPOUND_EXPRs with double-linked chain of statements
[500-1000] --Regenerate COMPOUND_EXPRs? What for?
mostly changes to block iterators + places in code that rely on the
fact that the whole function tree is kept, and final pass that
4) moving BIND_EXPRs and exception handling constructs to their own
tree What is this change? I'm not sure I understand what you are doing
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
on how to make this step less painful.
5) rewrite of make_edges  -- especially eh edges are created in
aRe-write to improve compile-time, create fewer edges, or what?
weird way currently, IMHO.
Is this acceptable? It will of course be a great lot of patches, so IIn principle, yes. I'm interested in your changes to expose control
won't go into it unless I know that someone is ready to take the
of reviewing them.
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
continue with the experimental changes until they're more stable.
Just as a note about stability, his patches pass all but 2 regression
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)