On Apr 17, 2006, at 11:52 AM, Mark Mitchell wrote:
Dan Berlin and I exchanged some email about PR 26435, which concerns a
bug in -ftree-loop-linear, and we now think it would make sense to
have
a broader discussion.
The PR in question is about an ice-on-valid regression in 4.1, when
using -O1 -ftree-loop-linear. Dan notes that this optimization option
is "experimental", but I didn't see that reflected in the
documentation,
which says:
@item -ftree-loop-linear
Perform linear loop transformations on tree. This flag can
improve cache
performance and allow further loop optimizations to take place.
I wasn't aware that it was supposed to be experimental either, and it
wasn't explained that way when it went in (Sep 2004). (Incomplete or
buggy would not be surprising, but it sounds now like we're talking
about fatally flawed design, which is different.)
In any case, the broader question is: to what extent should we have
experimental options in releases, and how should we warn users of
their
experimental nature?
In general I would agree in principle with Diego that such features
don't belong in releases, but this isn't the first time features have
been found to be buggy after they've gone in. -frename-registers
comes to mind; in that case, the bugginess was documented for several
releases, and that warning has recently been removed as the bugs are
believed to be fixed.
This optimization is worth about a 5x speedup on one of the SPECmarks
(see discussion in archives), so IMO we should consider carefully
before removing it. It was in 4.0 and 4.1 releases.
My suggestion is that features that are clearly experimental (like
this
one) should be (a) documented as such, and (b) should generate a
warning, like:
warning: -ftree-loop-linear is an experimental feature and is not
recommended for production use
Looks good to me.