IRA copy heuristics

[Vladimir Makarov]

Richard Sandiford wrote:
> Vladimir Makarov <vmakarov@redhat.com> writes:
>   
>> 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.
>>     
>
> Sorry Vlad, my reply to HJ crossed with your message.
>
> I'm really against applying the ALLOCNO_COMPARE patch.  Unlike the DF
> patch, It isn't needed to fix a correctness regression.  And it changes
> the heuristics _without any explanation of why this is necessary_.
> IMO, that's unacceptable for our shiny, new (and generally very nice)
> register allocator.  And I think it's unacceptable even if it happens
> to fix a performance regression.
>
> Experience suggests that if we apply this patch now, no-one will
> ever look at the deeper problem, and we'll be lumped with magic goo
> that no-one really understands.  After all, this issue is about three
> months old now.  (And that certainly isn't meant to be a criticism.
> We're all busy people.  But it's because we're busy people that I'm
> so reluctant to apply the patch.)
>
>   
Probably you are right.
> But as I said to HJ, I'm happy to apply the DF patch in isolation,
> as long as we accept that the benefit of fixing a correctness
> regression outweighs the potential performance regression.
>   
Sure, regression is more important.  Therefore even if you submit only 
one (reverse BB traverse) patch, it is ok for me.

As I wrote I am going to look at the second patch.  I have feeling that 
even without the second patch, there will be no performance regression.  
I think that my latest patches (some of them are not in the mainline 
yet) removed IRA instability toward allocno ordering.  I just need time 
to make sure about this.