search for: callsdnod

...li 0x08738f6d llvm::JIT::getPointerToFunction(llvm::Function*) + 755 7 lli 0x0873f704 8 lli 0x08597416 X86CompilationCallback2 + 166 9 lli 0x08596e08 X86CompilationCallback + 24 10 lli 0x00eebff5 X86CompilationCallback + 4170535429 11 lli 0x0863e13e llvm::CallSDNode::CallSDNode(unsigned int, llvm::DebugLoc, bool, bool, bool, llvm::SDVTList, llvm::SDValue const*, unsigned int, unsigned int) + 90 12 lli 0x08622d47 llvm::SelectionDAG::getCall(unsigned int, llvm::DebugLoc, bool, bool, bool, llvm::SDVTList, llvm::SDValue const*, unsigned int, unsigned int)...

On Tuesday 24 February 2009 22:19:27 Arnold Schwaighofer wrote: > What i was trying to say is that if you have > > i32 a() { > %1 = tailcall b() > ret %1 > } > > > i32 b() { > %1 = tailcall c() > ret %1 > } > > i32 c() { > %1 = tailcall d() > ret %1 > } > > i32 d() { > ret i32 5 > } > > only d() will actually

0, i32 %1) >> >> Note that if you have a series of sequential recursive tail calls this >> move will only performed once (at the bottom of the recursion, >> respectively when the recursion returns) so it's impact on performance >> should be minimal. > > Hmm, that makes it sound as though the moves between a tail call and the > following return are

...Keep track the number of ARM PC labels created. - /// + /// ARMPCLabelIndex - Keep track of the number of ARM PC labels created. unsigned ARMPCLabelIndex; + /// ARMJumpTableIndex - Keep track of the number ofJump Tables + unsigned ARMJumpTableIndex; SDValue LowerMemOpCallTo(CallSDNode *TheCall, SelectionDAG &DAG, const SDValue &StackPtr, const CCValAssign &VA, Index: lib/Target/ARM/ARMConstantPoolValue.h =================================================================== --- lib/Target/ARM/ARMConstantPoolValue.h (revision 72728) +++ lib...