[llvm-dev] Assertion "Node already inserted!" with glue code

Boris Boesler via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 5 08:39:59 PST 2015


Tom Stellard informed me, that the email was encrypted. Sorry.

The original email follows at the end. The core problem is that in my example the instruction selector creates two instructions, and each instruction has a glue-edge to a common subexpression. One instruction with an OutGlue and two instructions with an InGlue each. This case is illegal during scheduling, because the scheduler puts instructions connected with a glue-edge into one scheduling unit.

I have to find another solution.

Boris


> Am 04.11.2015 um 18:03 schrieb Boris Boesler via llvm-dev <llvm-dev at lists.llvm.org>:
> 
> I rewrote some patterns in my LLVM backend and now it fails in some cases and I have no idea why.
> 
> In my old backend I used a special IO register explicitly in the ins dag in one pattern to make sure that this IO register is initialized properly. Worked perfectly. But the hardware got some changes and to support future changes I have an explicit IO-register-write operation with an OutGlue property and with an implicit def of the IO register. I removed the explicit operand in the pattern and added an InGlue and an implicit use of the IO-register. Looks like a compare operation now and it works in most cases.
> 
> But there is a test program where the result of the instruction covered by the pattern should be stored in memory twice, but the instruction writes the result directly into memory. LLVM duplicates the instruction to write the result into memory a second time. There are now two glue-edges from the two instructions to the IO-write operation. This looks good after ISEL and prior to scheduling, but fails then with the assertion "Assertion failed: (N->getNodeId() == -1 && "Node already inserted!"), function BuildSchedUnits, file /somewhere/llvm/lib/CodeGen/SelectionDAG/ScheduleDAGSDNodes.cpp, line 364"
> And N is the IO-register-write operation.
> 
> Is my change illegal and not covered by the InGlue/OutGlue mechanism?
> 
> Every hint is welcome,
> Boris
> 


More information about the llvm-dev mailing list