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