On 02/23/2016 06:56 AM, Richard Biener wrote:
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?
This is a pathological case. It is not quadratic although we have
quadratic algorithms already in GCC. IRA building conflict graphs (as
the old global.c) can be quadratic for some pathological cases.
Actually reload + IRA can be slow as LRA for this case too if we takes
into account that reload is asking IRA to reallocate a spilled pseudo
each time.
But you are right for this case we can speed up LRA for such cases
considering rebuilding live info only for places where there are
changes. Probably it will speed up most other cases too.
