"Experimental" features in releases

[Dale Johannesen]

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.