Re: RFC: LRA for x86/x86-64 [0/9]

[Steven Bosscher <stevenb dot gcc at gmail dot com>]

On Mon, Oct 1, 2012 at 9:16 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Oct 01, 2012 at 08:47:13AM +0200, Steven Bosscher wrote:
>> The test case compiles just fine at -O2, only VRP has trouble with it.
>> Let's try to stick with facts, not speculation.
>
> I was talking about the other PR, PR26854, which from what I remember when
> trying it myself and even the latest -O3 time reports from the reduced
> testcase show that IRA/reload aren't there very significant (for -O3 IRA
> takes ~ 6% and reload ~ 1%).

OK, but what does LRA take? Vlad's numbers for 64-bits and looking at user time:

Reload: 503.26user
LRA: 598.70user

So if reload is ~1% of 503s then that'd be ~5s. And the only
difference between the two timings is LRA instead of reload, so LRA
takes ~100s, or 20%.


>> I've put a lot of hard work into it to fix almost all scalability problems
>> on this PR for gcc 4.8. LRA undoes all of that work. I understand it is
>> painful for some people to hear, but I remain of opinion that LRA cannot be
>> considered "ready" if it scales so much worse than everything else in the
>> compiler.
>
> Judging the whole implementation from just these corner cases and not how it
> performs on other testcases (SPEC, rebuild a distro, ...) is IMHO not the
> right thing, if Vlad thinks the corner cases are fixable during stage3; IMHO
> we should allow LRA in, worst case it can be disabled by default even for
> i?86/x86_64.

I'd be asked to do a guest lecture on compiler construction (to be
clear: I'd be highly surprised if anyone would ask me to, but for sake
of argument, bear with me ;-) then I'd start by stating that
algorithms should be designed for the corner cases, because the
devil's always in the details.

But more to the point regarding stage3: It will already be a busy
stage3 if the other, probably even more significant, scalability
issues have to be fixed, i.e. var-tracking and macro expansion. And
there's also the symtab work that's bound to cause some interesting
bugs still to be shaken out. With all due respect to Vlad, and,
seriously, hats off to Vlad for tacking reload and coming up with a
much easier to understand and nicely phase-split replacement, I just
don't believe that these scalability issues can be addressed in
stage3.

It's now very late stage1, and LRA was originally scheduled for GCC
4.9. Why the sudden hurrying? Did I miss the 2 minute warning?

Ciao!
Steven