This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Loop distribution for single nested loops
Sebastian Pop wrote:
> On Dec 9, 2007 5:59 PM, Mark Mitchell <mark@codesourcery.com> wrote:
Sebastian, thank you for being patient with me; I know that it's taken
me a long time to resume this thread.
>> 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 believe you've now fixed the ICE in apsi.f; I'm going to read further
to see if I can find that message.
> 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?
I don't think documentation is sufficient. We know that users ignore
it. If we provide a feature, it needs to work. I think that the fact
that we've historically been casual about this kind of thing leads to
the perception that GCC is never really as stable as the proprietary
competition.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713