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? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
