search for: emitnod

...o.6(__assert_fail+0xfd)[0x4caae859] /home/lefever/work/install/bin/llc(llvm::cast_retty<llvm::ConstantSDNode, llvm::SDOperand>::ret_type llvm::cast<llvm::ConstantSDNode, llvm::SDOperand>(llvm::SDOperand const&)+0x4c)[0x83f6af6] /home/lefever/work/install/bin/llc(llvm::ScheduleDAG::EmitNode(llvm::SDNode*, llvm::DenseMap<llvm::SDNode*, unsigned int, llvm::DenseMapKeyInfo<llvm::SDNode*> >&)+0x8b2)[0x86ab9fc] /home/lefever/work/install/bin/llc(llvm::ScheduleDAG::EmitSchedule()+0x283)[0x86abf7d] /home/lefever/work/install/bin/llc[0x861cada] /home/lefever/work/install/bi...

...fd)[0x4caae859] > /home/lefever/work/install/bin/llc(llvm::cast_retty<llvm::ConstantSDNode, > llvm::SDOperand>::ret_type llvm::cast<llvm::ConstantSDNode, > llvm::SDOperand>(llvm::SDOperand const&)+0x4c)[0x83f6af6] > /home/lefever/work/install/bin/llc(llvm::ScheduleDAG::EmitNode(llvm::SDNode*, > llvm::DenseMap<llvm::SDNode*, unsigned int, > llvm::DenseMapKeyInfo<llvm::SDNode*> >&)+0x8b2)[0x86ab9fc] > /home/lefever/work/install/bin/llc(llvm::ScheduleDAG::EmitSchedule()+0x283)[0x86abf7d] > /home/lefever/work/install/bin/llc[0x861cada] > /hom...

Sorry, still not enough information. I am guessing it's asserting in getVR() called from EmitNode()? The node is CopyToReg and it's trying to find the virtual register of operand 2? From the schedule, I don't see the definition of the operand. Can you do DAG.viewGraph()? That should gives us a better idea. Evan On Oct 16, 2007, at 9:06 PM, Scott Michel wrote: > Evan: > &g...

...59] >>/home/lefever/work/install/bin/llc(llvm::cast_retty<llvm::ConstantSDNode, >>llvm::SDOperand>::ret_type llvm::cast<llvm::ConstantSDNode, >>llvm::SDOperand>(llvm::SDOperand const&)+0x4c)[0x83f6af6] >>/home/lefever/work/install/bin/llc(llvm::ScheduleDAG::EmitNode(llvm::SDNode*, >>llvm::DenseMap<llvm::SDNode*, unsigned int, >>llvm::DenseMapKeyInfo<llvm::SDNode*> >&)+0x8b2)[0x86ab9fc] >>/home/lefever/work/install/bin/llc(llvm::ScheduleDAG::EmitSchedule()+0x283)[0x86abf7d] >>/home/lefever/work/install/bin/llc[0x861cad...

...uch. I am installing LLVM-3.2, but I encounter the next error when carrying out "make": llvm[3]: Compiling ClangASTNodesEmitter.cpp for Release+Asserts build ClangASTNodesEmitter.cpp: In member function ‘std::pair<llvm::Record*, llvm::Record*><unnamed>::ClangASTNodesEmitter::EmitNode(const std::multimap<llvm::Record*, llvm::Record*, std::less<llvm::Record*>, std::allocator<std::pair<llvm::Record* const, llvm::Record*> > >&, llvm::raw_ostream&, llvm::Record*)’: ClangASTNodesEmitter.cpp:80: error: ‘nullptr’ was not declared in this scope make[3]:...

Ok, I've had time to track this down a little bit more and I seem to have found another case where it fails. This is occurring during Schedulur->EmitSchedule() in SelectionDAGISel.cpp:695. The problem seems to be that somehow the CopyToReg part of the switch statement in ScheduleDAG::EmitNode has a FrameIndex as its second operand. This is especially problematic because the code is either expecting a VirtualRegister or a RegisterSDNode in this location. I've checked all locations where I use the DAG.getCopyToReg function and none of them pass in a frameindex. I explcitily check tha...

...a field to the SelectionDAGBuilder holding the current metadata which I update in SelectionDAGISel::SetDebugLoc() for every IR instruction. Next, in SelectionDAGBuilder::visit() i transfer the current instruction's metadata from the DAGBuilder to the instruction's SDNode. In InstrEmitter::EmitNode() I copy the metadata from the SDNode to the MachineInstr. DwarfDebug::endModule() creates my user-defined DIE (after defining my own DW_TAG and DW_AT IDs in Dwarf.h) and adds it to the ModuleCU (for simplicity I'm adding my DIEs to the module's debug_info section) I Added a few lines to...

Evan: What you requested was in the debug output (sans offending Node), but here it is, outside of the attachment. The offending node is highlighted: SU(0): 0xa908760: ch = EntryToken SU(1): 0xa907600: i32,ch,flag = CopyFromReg 0xa9095d0, 0xa9070e0, 0xa9095d0:1 0xa906e30: ch,flag = CopyToReg 0xa908760, 0xa9070e0, 0xa9071f0 <<--<<--<<--<<--<< Node

...b/CodeGen/SelectionDAG/ ScheduleDAG.cpp:269 #6 0x007c5218 in llvm::ScheduleDAG::EmitCopyFromReg (this=0x41a25a50, Node=0x41a17f60, ResNo=0, SrcReg=79, VRBaseMap=@0xbfffe218) at /Volumes/Gir/devel/llvm/llvm.src/lib/ CodeGen/SelectionDAG/ScheduleDAG.cpp:304 #7 0x007c5938 in llvm::ScheduleDAG::EmitNode (this=0x41a25a50, Node=0x41a17f60, VRBaseMap=@0xbfffe218) at /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:716 #8 0x007c5f00 in llvm::ScheduleDAG::EmitSchedule (this=0x41a25a50) at /Volumes/Gir/devel/llvm/llvm.src/lib/CodeGen/SelectionDAG/ ScheduleDAG.cpp:807 #9...

...me to track this down a little bit more and I seem to > have found another case where it fails. This is occurring during > Schedulur->EmitSchedule() in SelectionDAGISel.cpp:695. The problem > seems > to be that somehow the CopyToReg part of the switch statement in > ScheduleDAG::EmitNode has a FrameIndex as its second operand. This is > especially problematic because the code is either expecting a > VirtualRegister or a RegisterSDNode in this location. I've checked all Unfortunately, I don't think anyone can help you until you can track down what is creating the F...

...me/lefever/work/install/bin/llc(llvm::cast_retty<llvm::ConstantSDNode, > >>llvm::SDOperand>::ret_type llvm::cast<llvm::ConstantSDNode, > >>llvm::SDOperand>(llvm::SDOperand const&)+0x4c)[0x83f6af6] > >>/home/lefever/work/install/bin/llc(llvm::ScheduleDAG::EmitNode(llvm::SDNode*, > >>llvm::DenseMap<llvm::SDNode*, unsigned int, > >>llvm::DenseMapKeyInfo<llvm::SDNode*> >&)+0x8b2)[0x86ab9fc] > >>/home/lefever/work/install/bin/llc(llvm::ScheduleDAG::EmitSchedule()+0x283)[0x86abf7d] > >>/home/lefever/work/inst...

...VM-3.2, but I encounter the next error when carrying out > "make": > > llvm[3]: Compiling ClangASTNodesEmitter.cpp for Release+Asserts build > ClangASTNodesEmitter.cpp: In member function ‘std::pair<llvm::Record*, > llvm::Record*><unnamed>::ClangASTNodesEmitter::EmitNode(const > std::multimap<llvm::Record*, llvm::Record*, std::less<llvm::Record*>, > std::allocator<std::pair<llvm::Record* const, llvm::Record*> > >&, > llvm::raw_ostream&, llvm::Record*)’: > ClangASTNodesEmitter.cpp:80: error: ‘nullptr’ was not declared in...

...o modify the computeRegisterProperties to tell that f64 is actually represented as 2xi32. I also added some code into the function FunctionLoweringInfo::CreateRegForValue for allocating this pair of i32 regs for f64 values. But it does not seem to help. >From what I can see, the problem is that emitNode() still looks at the machine instruction descriptions. And since I still have some insns for load and stores of f64 values (do I still need to have them, if I do the mapping?), it basically allocates f64 registers without even being affected in any form by the modifications described above, becaus...

...g down a tricky bug involving select/CMOV and scheduling. In my test, I have a float select that has to be implemented with a diamond CFG by the scheduler. The high level ScheduleDAGSDNodes::EmitSchedule does this: for (unsigned i = 0, e = Sequence.size(); i != e; i++) { [...] Emitter.EmitNode(SU->getNode(), SU->OrigNode != SU, SU->isCloned, VRBaseMap); [...] } TheInstrEmitter::EmitMachineNode does this: if (II.usesCustomInsertionHook()) { // Insert this instruction into the basic block using a target // specific inserter which may returns...

....2). If they don't match, it won't compile. Regards, John Criswell > > llvm[3]: Compiling ClangASTNodesEmitter.cpp for Release+Asserts build > ClangASTNodesEmitter.cpp: In member function ‘std::pair<llvm::Record*, > llvm::Record*><unnamed>::ClangASTNodesEmitter::EmitNode(const > std::multimap<llvm::Record*, llvm::Record*, std::less<llvm::Record*>, > std::allocator<std::pair<llvm::Record* const, llvm::Record*> > >&, > llvm::raw_ostream&, llvm::Record*)’: > ClangASTNodesEmitter.cpp:80: error: ‘nullptr’ was not declared...

...xpand' and to get TLI.getTypeToTransformTo(f64) to return i32. > I also added some code into the function > FunctionLoweringInfo::CreateRegForValue for allocating this pair of i32 > regs for f64 values. But it does not seem to help. Ok. > From what I can see, the problem is that emitNode() still looks at the > machine instruction descriptions. And since I still have some insns for > load and stores of f64 values (do I still need to have them, if I do > the mapping?), it basically allocates f64 registers without even being > affected in any form by the modifications des...

...if appropriate. See <URL:http://llvm.org/bugs> for instructions. a backtrace in cc1 shows: (gdb) bt #0 0xf7da55df in raise () from /lib32/libc.so.6 #1 0xf7da6b13 in abort () from /lib32/libc.so.6 #2 0xf7d9edac in __assert_fail () from /lib32/libc.so.6 #3 0x085c63f4 in llvm::ScheduleDAG::EmitNode () (gdb) i would like to fix this bug, but it is hard to tell the real source of the problem: 1.) it could be an error during the legalization. sharing the constant node could be prevented. this would not cause the instruction selector to rewrite the constant node. 2.) the error is in the instr...

Hi Roger, On Mon, Aug 23, 2010 at 4:01 PM, Roger Wang <innit42 at gmail.com> wrote: > Dear all, > > I'd like to find the memory location of certain instructions in a > compiled/linked binary. During the IR phase, I tag instructions I'm > interested in with LLVM'-2.7's new metadata (MDNodes with an identifiable > ID). I'd now like to propagate that data

Other than not using debugging ('-g' and the like), not really. :-( I think that Devang is actively working on fixing this, though. It might not be too much longer. -bw On Thu, Jan 15, 2009 at 3:26 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > This did not seem to work, any other ideas? > > Thanks, > > -----Original Message----- > From: llvmdev-bounces at

Dear all, I'd like to find the memory location of certain instructions in a compiled/linked binary. During the IR phase, I tag instructions I'm interested in with LLVM'-2.7's new metadata (MDNodes with an identifiable ID). I'd now like to propagate that data to the assembly via a custom DWARF tag I attach to each X86 instruction created from a tagged IR instruction. This will