
The problem is that this instruction requires three separate registers, but cmpxchgl already reads and writes %eax leaving only two free registers (%ecx and %edx). You'll need to arrange to not use the complicated addressing modes with cmpxchg on i386, and keep the number of free regs required <= 2. Really we ought to have 4 usable regs, but for that to happen we need to change the calling convention and swap R1 with Sp, but we can't easily do that because it needs a change in LLVM too (sigh). Cheers, Simon On 26/06/2014 19:39, Johan Tibell wrote:
Here's some more debug output. Can someone interpret it:
genRaInsn cmpxchgl %vI_n1nF,8(%vI_n1nD,%vI_n1nE,4) r_dying = [%vI_n1nD, %vI_n1nE, %vI_n1nF] w_dying = [] virt_read = [%vI_n1nD, %vI_n1nE, %vI_n1nF] virt_written = [] freeregs = FreeRegs 4282318848 assig = [n1nD :-> InMem 0, n1nE :-> InReg (RealRegSingle 2), n1nF :-> InReg (RealRegSingle 3)] ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140626 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1nD assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle 2)),(n1nF,InReg (RealRegSingle 3))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861
(i.e. it's the cmpxchg instruction which is causing the failure.)
On Thu, Jun 26, 2014 at 8:17 PM, Johan Tibell
mailto:johan.tibell@gmail.com> wrote: I'm trying to understand the output from the register allocator:
(GHC version 7.9.20140626 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1nD assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle 2)),(n1nF,InReg (RealRegSingle 3))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861
Without understanding exactly what's wrong, the message above suggests that we're trying to allocate a reg for n1nD, but there's already an assignment for that virtual reg, is that right?
On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell
mailto:johan.tibell@gmail.com> wrote: Herbert pushed my revert for me a minute ago. Everyone should be good once they sync.
On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell
mailto:johan.tibell@gmail.com> wrote: I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed this morning) which is fine. You should be in a good state now when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.
On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones
mailto:simonpj@microsoft.com> wrote: git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 ____
[master f958079] Revert "Add more primops for atomic ops on byte arrays"____
23 files changed, 86 insertions(+), 1016 deletions(-)____
rewrite compiler/nativeGen/CPrim.hs (62%)____
delete mode 100644 libraries/ghc-prim/cbits/atomic.c____
delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs____
delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout____
HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 ____
fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177____
HEAD $____
What now?____
Simon____
__ __
*From:*Johan Tibell [mailto:johan.tibell@gmail.com mailto:johan.tibell@gmail.com] *Sent:* 26 June 2014 13:25 *To:* Simon Peyton Jones *Cc:* Karel Gardas; ghc-devs *Subject:* Re: Two days old build breakage on i386.____
__ __
Just to make sure this is the same breakage, are you on an i386 Windows machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.____
__ __
On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones
mailto:simonpj@microsoft.com> wrote:____ Aaaargh! Once again the Windows build is broken. I am utterly stalled.
Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. At least they should elicit warnings saying that they are disabled pending the fix to X and Y.
Please can someone bisect to find out which patch is the culprit?
I wish we had a more systematic way to find this out. I hate being the main person who gets stuck because some unrelated change has broken the Windows build. (Thanks for Karel, who got to it a day before me.)
Thanks
Simon____
| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org mailto:ghc-devs-bounces@haskell.org] On Behalf Of Karel | Gardas | Sent: 26 June 2014 09:56 | To: ghc-devs; Johan Tibell | Subject: Two days old build breakage on i386. | | | Hello, | | builders running on i386 building for this platform caught issue which | shows as a build breakage: | | ghc-stage1: panic! (the 'impossible' happened) | (GHC version 7.9.20140624 for i386-unknown-linux): | RegAllocLinear.allocRegsAndSpill: no spill candidates | allocating vreg: VirtualRegI n1Q6 | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] | freeRegs: FreeRegs 4282318848 | initFreeRegs: FreeRegs 4282318861 | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug | make[1]: *** | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 | libraries/ghc-prim/ghc.mk:4 http://ghc.mk:4: recipe for target | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed | | Have a look for example on linux-i386 buildot log here: | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html | | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so | it's OS independent and probably 32bit/i386 platform specific and it's | two days old breakage now. The last two night builds fail on all | mentioned buildbots. I'm not sure but perhaps: | | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 | Author: Johan Tibell
mailto:johan.tibell@gmail.com> | Date: Mon Jun 9 11:43:21 2014 +0200 | | triggers that issue? I'm not claiming that the commit is actual culprit, | this may be just recently un-hidden issue in linear regs allocator on | i386! | | Thanks! | Karel____ | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org mailto:ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs____
__ __