Richard Sandiford wrote:
Vladimir Makarov <[EMAIL PROTECTED]> writes:
Richard Sandiford wrote:
"H.J. Lu" <[EMAIL PROTECTED]> writes:
On Tue, Sep 2, 2008 at 8:37 AM, Vladimir Makarov <[EMAIL PROTECTED]> 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.

Reply via email to