On 12-10-01 6:30 AM, Bernd Schmidt wrote:
On 10/01/2012 12:14 PM, Jakub Jelinek wrote:
On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:
I would also agree if it were not for the fact that IRA is already a
scalability bottle-neck and that has been known for a long time, too.
I have no confidence at all that if LRA goes in now, these scalability
problems will be solved in stage3 or at any next release cycle. It's
always the same thing with GCC: Once a patch is in, everyone moves on
to the next fancy new thing dropping the not-quite-broken but also
not-quite-working things on the floor.
If we open a P1 bug for it for 4.8, then it will need to be resolved some
way before branching. I think Vlad is committed to bugfixing LRA, after
all the intent is for 4.9 to enable it on more (all?) targets, and all the
bugfixing and scalability work on LRA is needed for that anyway.
Why can't this be done on the branch? We've made the mistake of rushing
things into mainline too early a few times before, we should have
learned by now. And adding more half transitions is not something we
really want either.
I should clearly express that the transition will be not happen for
short time because of the task complexity. I believe that lra will
coexist with reload for 1-2 releases. I only ported LRA for 9 major
targets. The transition completion will be dependent on secondary
target maintainers too because I alone can not do porting LRA for all
supported targets. It was discussed with a lot of people on 2012 GNU
Tools Cauldron. Maintenance of LRA on the branch is a big burden, even
x86-64 is sometimes broken after merge with the trunk.
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 in the importance of this work as LLVM catches GCC on RA front
by implementing a new RA for LLVM3.0. I believe we should get rid off
reload as outdated, hard to maintain, and preventing implementation of
new RA optimizations.
In any case submitting the patches was a good thing to do because I got
a lot of feedback. I still appreciate any comments on the patches.
