Hi Andrew, On Wed, 25 Oct 2006, Andrew Haley wrote: > I must admit to being a little perplexed by this. > > We have an unsafe optimization that causes bad code to be generated on > at least one platform. However, we want to continue to perform this > unsafe optimization on our release branch until we are sure that > removing it doesn't cause performance regressions. And, perhaps, if > removing the optimization does cause performance regressions we won't > remove it, preferring bad code to reduced performance. > > Is that a fair summary? Perhaps I'm misunderstanding what you wrote.
The issue is that there are two possible fixes to this problem... This wrong code regression was introduced by the recent bug-fix patch to address an aspect of PR middle-end/28690, a missed optimization regression affecting gcc 4.2 and 4.3. That change then exposed a latent bug in the RTL optimizers that has been there 2002. The ultra-conservative approach would be to simply back-out the patch that exposed the bug, and simply accept the performance degradation. The alternative is to progress towards "our ideal world" by actually fixing the problem rather than working around the issue. Unfortunately, moving forward is itself not without risk, both to the tree's stability and to the performance impact of removing an optimization that's been there for years. The fixes trade-off one performance issue against the possibility of another. In my professional judgement as a middle-end maintainer, the appropriate course is to move mainline forward to better evaluate the risks and tradeoffs of the proposed changes. Then depending upon the outcome, decide which of the two solutions should be backported to the release branches. Given the expected release timings, it makes sense to avoid "acting in haste" and to make the right decision. If we're in a rush, I'd push for reverting the PR28690 from the release branch and return us to a known state, and accept the performance loss. But if Richard Sandiford's and David Daney's patch works out, we can correct the wrong-code issue, without the performance loss. Once explained, I'd expect most maintainers would make precisely the same call? Roger --
