Fix/work around PR57676, LRA terminates prematurely

Jeff Law law@redhat.com
Wed Feb 24 22:01:00 GMT 2016


On 02/23/2016 04:56 AM, Richard Biener wrote:
> On Mon, Feb 22, 2016 at 4:34 PM, Jeff Law <law@redhat.com> wrote:
>> On 02/22/2016 07:34 AM, Richard Biener wrote:
>>
>>> Hum, but then you get to "inifinite" compiles again when LRA is buggy
>>> or the user presents it with an impossible to handle asm.
>>
>> Neither should be happening in practice, even an impossible asm should cause
>> LRA to halt in some way or another.
>>
>> In practice looping has occurred due to bugs in machine descriptions are are
>> typically seen during development/porting.  Hence the desire to put it under
>> -fchecking for gcc-6 and possibly implement something smarter for gcc-7
>> (where we'd track more precisely whether or not we're making forward
>> progress).
>>
>>>
>>> I don't think that's a good idea - maybe bumping the limit is the way to
>>> go instead?
>>
>> No, because one just needs to build a longer chain of insns needing
>> reloading.
>>
>>>
>>> 30 constraint passes sounds excessive and a sign of a bug to me anyway.
>>
>> Not really.  If you look at the testcase and the chain of reloads, it's
>> legitimate.  Essentially each pass exposes a case where spill a register in
>> an insn that previously had a register allocated.
>
> But requiring another full reload pass to handle such chains is pointing at
> a wrong algorithm IMHO.  Isn't this also quadratic in the length of the chain?
Note that reload behaves similarly.  Not for this exact case, but it's 
essentially a "keep iterating until nothing changes" algorithm.  It's 
just so poor in its ability to assign things to registers that these 
deep chains are rare.

As Vlad noted, the test is definitely a pathological case.  I think 
Bernd's patch is a very reasonable approach to address the current 
problem.  Namely that LRA can be making progress on a pathological 
testcase, but it gets terminated by the anti-looping clamp.  The clamp 
itself was put in place to catch bugs in LRA or ports that are in the 
process of converting to LRA.

Jeff



More information about the Gcc-patches mailing list