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



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)


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