This is the mail archive of the 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: [patch] Loop distribution for single nested loops

On Dec 9, 2007 5:59 PM, Mark Mitchell <> wrote:
> I don't think enabled-by-default is a good decision criteria for these
> things.  "Technology previews' are fine -- but I believe that releasing
> code that isn't well-tested just hurts us.  In practice, people find the
> documentation for these options, turn them on, notice that small
> examples work great, and then find problems in large programs.  I think
> the GCC project is better served by ensuring that these things aren't
> released until we're confident in them.  I'm certainly aware of the
> "more testing" argument -- but I think testing ought to be done by us.

For the stability point of view, the patch that I sent passed the spec
cpu2000 with -O2 -ftree-loop-distribution on i686-linux, distributing
242 loops.  There were no miscompares, but I got an ICE due to the
loop-closed-ssa form in apsi.f, that I'm fixing now.  The patch also
passed cpu2006 with -O3 -ftree-loop-distribution on amd64-linux,
distributing 1342 loops, with no ICEs nor miscompares.

I will also report the results of loop distribution in combination
with vectorization and parallelization, as it is in combination with
these code generation passes that loop distribution is profitable.

As a side note, IMO the options that are not enabled by default are
less dangerous than patches to fix PRs in code enabled at -O2.  Always
IMO, the "technology preview" passes could be considered as new ports.
What about documenting the status of the new passes in invoke.texi
such that adventurous programmers try these options with care?

AMD - GNU Tools

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