Dale Johannesen wrote: > 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.)
My understanding from clarifications from others is that this loop nest bit is somehow not quite right, but that most of it is solid. So, I think that I may have read more into Dan's mail than he intended. We shouldn't just to drastic conclusions, but there certainly is something to be clarified here. > 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. Indeed. My understanding is we might be able to remove just the problematic part (or segregate that into a separate option) -- but that problematic part is the 177.swim bit, so that's an issue. You're completely right that all new features are more likely to have defects than older features. There's no clear line between experimental and non-experimental features, but sometimes it may be obvious into which category a feature falls. >> 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. Good. Independent of this issue, I'd certainly like to get consensus on the general question. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
