This is the mail archive of the
gcc@gcc.gnu.org
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 [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)