This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IRA copy heuristics


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.)

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.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]