search for: conservativelyallocatablenodes

...s of the narrow reg-class, and the cost vector has become all infinities. Spill option is selected again, and thus the error is a fact of spilling an already spilled value. I wonder what has gone wrong here, and have some initial thoughts: * The problematic node that was spilled again, was in the ConservativelyAllocatableNodes set during reduce(). The comment in reduce() "Conservatively allocatable nodes will never spill..." indicates that perhaps this is an incorrect insertion, as the regs did in fact run out in this case. In setup(), the node is first put into not-provably-allocatables. However, one of it&...

...rnaud From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames Sent: 27 January 2015 06:06 To: Jonas Paulsson Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] PBQP crash Hi Jonas, > * The problematic node that was spilled again, was in the ConservativelyAllocatableNodes set during reduce(). The comment in reduce() “Conservatively allocatable nodes will never spill…” indicates that perhaps this is an incorrect insertion, as the regs did in fact run out in this case. Arnaud is correct: A node should never be put into the conservatively allocatable list if there...

...t cs.uiuc.edu] *On > Behalf Of *Lang Hames > *Sent:* 27 January 2015 06:06 > *To:* Jonas Paulsson > *Cc:* llvmdev at cs.uiuc.edu > *Subject:* Re: [LLVMdev] PBQP crash > > > > Hi Jonas, > > > > > * The problematic node that was spilled again, was in the > ConservativelyAllocatableNodes set during reduce(). The comment in reduce() > “Conservatively allocatable nodes will never spill…” indicates that perhaps > this is an incorrect insertion, as the regs did in fact run out in this > case. > > > > Arnaud is correct: A node should never be put into the conservati...

...blyAllocatableNodes. G.setEdgeCosts() is called and then the call stack grows with Solver->handleSetEdgeCosts(), handleRemoveEdge() into handleDisconnectEdge(), where NMd.handleRemoveEdge() is called, which decreases the DeniedOpts by one. After this, it looks like a bug to me that Z is moved to ConservativelyAllocatableNodes, because eventually handleSetEdgeCosts() will complete, and the edge between Y and Z will have been added again in handleAddEdge(), and Z:DeniedOpts is again 8! I think this also shows up in a test case for arm. It was found by using the assert mentioned above, and running 'bin/llvm-stress -si...

...G.setEdgeCosts() is called and then the call > stack grows with Solver->handleSetEdgeCosts(), handleRemoveEdge() into > handleDisconnectEdge(), where NMd.handleRemoveEdge() is called, which > decreases the DeniedOpts by one. After this, it looks like a bug to me that > Z is moved to ConservativelyAllocatableNodes, because eventually > handleSetEdgeCosts() will complete, and the edge between Y and Z will have > been added again in handleAddEdge(), and Z:DeniedOpts is again 8! > > > > I think this also shows up in a test case for arm. It was found by using > the assert mentioned above, an...