[LLVMdev] Handling of DebugLocs during CSE of SelectionDAG nodes. (original) (raw)
Kyriakos Georgiou kyriakos at xmos.com
Tue Sep 13 04:01:19 PDT 2011
- Previous message: [LLVMdev] Weird GIMPLE by gccgo
- Next message: [LLVMdev] Handling of DebugLocs during CSE of SelectionDAG nodes.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I've been investigating a case with the XCore target (which doesn't use FastISel) where the DWARF line number emitted at -O0 results in the xgdb visiting source lines in an unexpected order. I've tracked down the problem to the handling of DebugLocs in the selection DAG, in the getNode method shown bellow.
It first tries to find if a similar node already exists in order to use that one otherwise it creates a new one. The problem of this approach is that it will wrongly use the line number debug info from the first node it will find. I can not see any reasonable way of dealing with that, but only dropping the line number info from that node in order to keep the debugger behaving correctly. Is that the correct approach? Are there any other suggestions?
02367 /// getNode - Gets or creates the specified node. 02368 /// 02369 SDValue SelectionDAG::getNode(unsigned Opcode, DebugLoc DL, EVT VT) { 02370 FoldingSetNodeID ID; 02371 AddNodeIDNode(ID, Opcode, getVTList(VT), 0, 0); 02372 void *IP = 0; 02373 if (SDNode *E = CSEMap.FindNodeOrInsertPos(ID, IP)) 02374 return SDValue(E, 0); 02375 02376 SDNode *N = new (NodeAllocator) SDNode(Opcode, DL, getVTList(VT)); 02377 CSEMap.InsertNode(N, IP); 02378 02379 AllNodes.push_back(N); 02380 #ifndef NDEBUG 02381 VerifySDNode(N); 02382 #endif 02383 return SDValue(N, 0); 02384 }
- Previous message: [LLVMdev] Weird GIMPLE by gccgo
- Next message: [LLVMdev] Handling of DebugLocs during CSE of SelectionDAG nodes.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]