This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix/work around PR57676, LRA terminates prematurely


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?

Richard.

> Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]