This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix/work around PR57676, LRA terminates prematurely
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Bernd Schmidt <bschmidt at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Vladimir Makarov <vmakarov at redhat dot com>
- Date: Mon, 22 Feb 2016 08:34:20 -0700
- Subject: Re: Fix/work around PR57676, LRA terminates prematurely
- Authentication-results: sourceware.org; auth=none
- References: <56C76BF6 dot 7080409 at t-online dot de> <56C78A0A dot 1020206 at redhat dot com> <56C78A75 dot 6020104 at redhat dot com> <CAFiYyc2TrdaKe5eXEnk8r6JY9T-oJwRcG5AbqRCtRAULkAOEAw at mail dot gmail dot com>
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.
Jeff