search for: csemap

...-- E: ----------------------------------------------------------- 0x89f8ea0: i32 = ConstantPool < declare int %puts(sbyte*) > 0 ----------------------------------------------------------- This can be reproduced by running "llvm-as hello.ll -o - | llc -march=arm". Is this a bug in CSEMap? Best Regards, Rafael

I think that the problem is in SelectionDAG::getConstantPool itself. Only Alignment and Offset are used in the ID. This causes false aliases. X86TargetLowering::LowerFABS should also be affected. All of its calls to getConstantPool have the same alignment and offset. Best Regards, Rafael

On Mon, 14 Aug 2006, [UTF-8] Rafael Esp?ndola wrote: > I think that the problem is in SelectionDAG::getConstantPool itself. > Only Alignment and Offset are used in the ID. This causes false > aliases. Doh. Sorry about that, I just checked in a fix. Please verify that this corrects the problem. > X86TargetLowering::LowerFABS should also be affected. All of its calls > to

...re 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,...

...re code in the XCore backend that needs to be maintained over time I'd rather explore other options first. Is there a view on which of the following approaches is better in general when two nodes with debug locations are merged because of CSE (either in the MachineCSE pass or because of the CSEMap in the SelectionDAG): 1) Use the DebugLoc of either of the pair of nodes (chosen arbitrarily). 2) Throw away the line number information on the merged node since it is not possible to preserve the information that operation is associated with multiple lines. The current approach seems to be 1)...

...67 /// 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)...

On Sep 14, 2011, at 7:37 AM, Richard Osborne wrote: > Is there a view on which of the following approaches is better in > general when two nodes with debug locations are merged because of CSE > (either in the MachineCSE pass or because of the CSEMap in the > SelectionDAG): > > 1) Use the DebugLoc of either of the pair of nodes (chosen arbitrarily). > 2) Throw away the line number information on the merged node since it is > not possible to preserve the information that operation is associated > with multiple lines. >...

...d Olesen wrote: > > On Sep 14, 2011, at 7:37 AM, Richard Osborne wrote: > >> Is there a view on which of the following approaches is better in >> general when two nodes with debug locations are merged because of CSE >> (either in the MachineCSE pass or because of the CSEMap in the >> SelectionDAG): >> >> 1) Use the DebugLoc of either of the pair of nodes (chosen arbitrarily). >> 2) Throw away the line number information on the merged node since it is >> not possible to preserve the information that operation is associated >> wit...

...te Zilog Z80 Backend. > I have succesfully created basic infrastructure and now trying to extend Z80InstrInfo.td to handle more and more C code. > I have done some work with FrameIndex and now I am stuck with assert. > > llc: SelectionDAG.cpp:645: bool llvm::SelectionDAG::RemoveNodeFromCSEMaps(llvm::SDNode*): Assertion `N->getOpcode() != ISD::EntryToken && "EntryToken in CSEMap!"' failed. > > This code works: > > void simple() > { > unsigned char i=10; > unsigned char a = 20; > } > > and produces my somewhat not VERY REAL z80 ass...

Hi, For my research, I need to reshape the current ARM backend to support armv2a. Zero-extend half word load (ldrh) is not supported by armv2a, so I need to make the code generation to not generate ldrh instructions. I want to replace all those instances with a 32-bit load (ldr) and then and the result with 0xffff to mask out the upper bits. These are the modifications that I have made to

..., MemVT, Ops, DynOps, NumOps, MMO, - Ordering, SynchScope); + SuccessOrdering, FailureOrdering, + SynchScope); CSEMap.InsertNode(N, IP); AllNodes.push_back(N); return SDValue(N, 0); } SDValue SelectionDAG::getAtomic(unsigned Opcode, SDLoc dl, EVT MemVT, - SDValue Chain, SDValue Ptr, SDValue Cmp, - SDValue Swp, MachinePointerInfo PtrInfo, -...