IRA copy heuristics

[Vladimir Makarov]

Richard Sandiford wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>   
>> On Tue, Sep 2, 2008 at 8:37 AM, Vladimir Makarov <vmakarov@redhat.com> wrote:
>>     
>>>> If using DF seems like the Right Thing, we could simply apply both
>>>> patches, which would give a similar same allocno order to the one
>>>> we have now.  But it seemed better to look a bit deeper first...
>>>>
>>>>         
>>> Richard, please apply the both patches.  As I wrote above there is no
>>> SPECFP regression anymore with the patches.  They also solves some
>>> testsuite regressions concerning EH.
>>>
>>>       
>> Hi Richard,
>>
>> Could you please apply your use DF patch? It fixes EH regressions
>> as well as 434.zeusmp in SPEC CPU 2006?
>>     
>
> As I said yesterday, I'm reluctant to apply the first patch,
> because without further analysis, there's a danger it's just
> papering over a deeper problem.
>
> It's interesting that it fixes EH regressions for you too though.
> That was what the patch was originally meant to do, but I thought
> I'd only seem the regressions I was fixing on MIPS, not on x86_64.
> Which target did you see them on?
>
>   
Richard, please apply the both patches because I know that they will not 
introduce performance regression.  I'll check what happens to SPEC2000 
without the second patch (allocno ordering) later.  If it is ok we could 
remove the second patch.

Processing pseudos on reverse traverse of BBs is important to set up 
conflicting hard registers for allocnos because DF does not put all hard 
registers on LR_IN or LIVE_IN as the common sense says me.  I don't know 
what are reasons for this.  It was not a problem for the old RA because 
it was converted to build conflict graph on reverse BB traverse some 
time ago.

This problem affects not only MIPS.  I saw such problem at least on IA64.

If you want, I could commit the patches (because they are not mine).  
Please, just let me know.