On Mon, Feb 22, 2016 at 4:34 PM, Jeff Law <l...@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
