On Mon, Oct 1, 2012 at 10:51 AM, Vladimir Makarov <vmaka...@redhat.com> wrote: > > When I proposed merge LRA to gcc4.8, I had in mind that: > o moving most changes from LRA branch will help LRA maintenance on the > branch and I'll have more time to work on other targets and problems. > o the earlier we start the transition, the better it will be for LRA > because LRA on the trunk will have more feedback and better testing. > > I've chosen x86/x86-64 for this because I am confident in this port. On > majority of tests, it generates faster, smaller code (even for these two > extreme tests it generates 15% smaller code) for less time. IMO, the slow > compilation of the extreme tests are much less important than what I've just > mentioned. > > But because I got clear objections from at least two people and no clear > support for the LRA inclusion (there were just no objections to include it), > I will not insists on LRA merge now.
I believe that we should proceed with the LRA merge as Vlad has proposed, and treat the compilation time slowdowns on specific test cases as bugs to be addressed. Clearly these slowdowns are not good. However, requiring significant work like LRA to be better or equal to the current code in every single case is making the perfect the enemy of the good. We must weigh the benefits and drawbacks, not require that there be no drawbacks at all. In this case I believe that the benefits of LRA significantly outweigh the drawbacks. Steven is correct in saying that there is a tendency to move on and never address GCC bugs. However, there is also a counter-vailing tendency to fix GCC bugs. Anyhow I'm certainly not saying that in all cases it's OK to accept a merge with regressions; I'm saying that in this specific case it is OK. (I say all this based on Vlad's descriptions, I have not actually looked at the patches.) Ian
