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

[Richard Guenther <richard dot guenther at gmail dot com>]

On Mon, Oct 1, 2012 at 7:48 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Sun, Sep 30, 2012 at 06:50:50PM -0400, Vladimir Makarov wrote:
>>   But I think that LRA cpu time problem for this test can be fixed.
>> But I don't think I can fix it for 2 weeks.  So if people believe
>> that current LRA behaviour on this PR is a stopper to include it
>> into gcc4.8 than we should postpone its inclusion until gcc4.9 when
>> I hope to fix it.
>
> I think this testcase shouldn't be a show stopper for LRA inclusion into
> 4.8, but something to look at for stage3.

I agree here.

> I think a lot of GCC passes have scalability issues on that testcase,
> that is why it must be compiled with -O1 and not higher optimization
> options, so perhaps it would be enough to choose a faster algorithm
> generating worse code for the huge functions and -O1.

Yes, we spent quite some time in making basic optimization work for
insane testcases (basically avoid quadratic or bigger complexity in any
IL size variable (number of basic-blocks, edges, instructions, pseudos, etc.)).

And indeed if you use -O2 we do have issues with existing passes (and even
at -O1 points-to analysis can wreck things, or even profile guessing - see
existing bugs for that).  Basically I would tune -O1 towards being able to
compile and optimize insane testcases with memory and compile-time
requirements that are linear in any of the above complexity measures.

Thus, falling back to the -O0 register allocating strathegy at certain
thresholds for the above complexity measures is fine (existing IRA
for example has really bad scaling on the number of loops in the function,
but you can tweak with flags to make it not consider that).

> And I agree it is primarily a bug in the generator that it creates such huge
> functions, that can't perform very well.

Well, not for -O2+, yes, but at least we should try(!) hard.

Thanks,
Richard.

>         Jakub