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.
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?
On the one hand, it is of course useful to get additional testing and
feedback for new features. On the other, users of GCC will twist the
knobs we give them, and if there's no obvious way to know that they're
doing something dangerous, they'll have a negative reaction when things
go wrong.
In this particular case, Dan wrote:
There is really no easy way to fix the code that exists there now, it
was meant to be a temporary hack. It's not quite algorithmically sound.
If it's really a temporary hack, then it's not clear that we're getting
much useful testing by exposing it to users. And, if it's not
algorithmically sound, then it seems users should be warned away from
it. The obvious counter-argument is that there are certainly known bugs
in -O2, and yet we don't warn people not to use -O2. So, it doesn't
make sense to have a bright-line rule.
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
At least we're ensuring that even someone copying someone else's
Makefile is aware that they're in dangerous territory.
Thoughts?