Plan to merge LRA.

Plan to merge LRA.

[Vladimir Makarov]

   I'd like to commit LRA patches on the Sunday.  I got a lot of 
feedback about LRA for a few last weeks.  All patches besides RA part 
were approved by Jeff Law.  Steven Bosscher and I solved LRA speed 
problem on famous PR54146.  Now Steven does not object to LRA merge.

   I got invaluable reviews of LRA parts from Richard Sandiford.  I 
guess Richard thought deeply about reload for a long time.  His 
proposals were very useful and made LRA code much more clear.

   I'd like to thank all these people for their help and spending a lot 
of time on reviews and LRA work.

   So my plan is to merge trunk into LRA branch first and, if it looks 
ok, commit LRA to the trunk on Sunday to be ready solve problems (if 
there are any) starting Monday morning EST.  LRA merge will affect only 
x86/x86-64 target.  If you suspect any problem with LRA and have no 
quick response from me, you can easily switch it off by putting false 
instead of true in function i386.c::lra_p and continue your work until 
the problem is solved by me.

   The work on LRA will be continued on the branch.  There are still few 
proposals non-critical for x86/x86-64 which will be implemented on the 
branch.  After some stabilization of LRA branch for other targets, it 
would be nice if target maintainers look at the branch. It will make 
transitions of more targets to LRA more smoothly when development of 
gcc4.9 starts.

Vlad.

Re: Plan to merge LRA.

[Diego Novillo]

On 2012-10-19 10:31 , Vladimir Makarov wrote:

>    So my plan is to merge trunk into LRA branch first and, if it looks
> ok, commit LRA to the trunk on Sunday to be ready solve problems (if
> there are any) starting Monday morning EST.  LRA merge will affect only
> x86/x86-64 target.  If you suspect any problem with LRA and have no
> quick response from me, you can easily switch it off by putting false
> instead of true in function i386.c::lra_p and continue your work until
> the problem is solved by me.

Thanks for the heads up, Vlad.  Does the branch have a lot of VEC() 
code?  I will need to adjust my VEC changes after you committed LRA.

I am still battling GTY failures, so I will wait until LRA is in trunk 
and stabilized before I push my VEC rewrite.


Thanks.  Diego.

Re: Plan to merge LRA.

[Vladimir Makarov]

On 12-10-19 11:46 AM, Diego Novillo wrote:
> On 2012-10-19 10:31 , Vladimir Makarov wrote:
>
>>    So my plan is to merge trunk into LRA branch first and, if it looks
>> ok, commit LRA to the trunk on Sunday to be ready solve problems (if
>> there are any) starting Monday morning EST.  LRA merge will affect only
>> x86/x86-64 target.  If you suspect any problem with LRA and have no
>> quick response from me, you can easily switch it off by putting false
>> instead of true in function i386.c::lra_p and continue your work until
>> the problem is solved by me.
>
> Thanks for the heads up, Vlad.  Does the branch have a lot of VEC() 
> code?  I will need to adjust my VEC changes after you committed LRA.
>
I counted 4 vectors (with about 25 lines referencing them).  One vector 
(point_freq_vec) is analogous to IRA.
> I am still battling GTY failures, so I will wait until LRA is in trunk 
> and stabilized before I push my VEC rewrite.
>

Re: Plan to merge LRA.

[Diego Novillo]

On 2012-10-19 11:51 , Vladimir Makarov wrote:

> I counted 4 vectors (with about 25 lines referencing them).  One vector
> (point_freq_vec) is analogous to IRA.

Perfect.  That shouldn't be hard at all then.  Thanks.


Diego.