search for: tailjmping

tailcall optimization stop working in jit (lli) in revision 45527. i guess this is because the jit is tailjmping to the wrong function address. the following change would reenable tailcallopt in jit. But i am pretty sure that this is not the correct fix (since i don't really understand what is going on :). maybe evan can comment on this? regards arnold Index: lib/Target/X86/X86CodeEmitter.cpp ====...

In X86CodeGen.cpp, the following code appears in the handler used for CALL64pcrel32 instructions: // Assume undefined functions may be outside the Small codespace. bool NeedStub = (Is64BitMode && (TM.getCodeModel() == CodeModel::Large || TM.getSubtarget<X86Subtarget>().isTargetDarwin())) || Opcode == X86::TAILJMPd;

On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > In X86CodeGen.cpp, the following code appears in the handler used for > CALL64pcrel32 instructions: > > // Assume undefined functions may be outside the Small > codespace. > bool NeedStub = > (Is64BitMode && > (TM.getCodeModel() == CodeModel::Large || >

On Thu, Jun 11, 2009 at 12:54 PM, Evan Cheng<evan.cheng at apple.com> wrote: > > > > On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > >> In X86CodeGen.cpp, the following code appears in the handler used for >> CALL64pcrel32 instructions: >> >>       // Assume undefined functions may be outside the Small codespace. >>       bool NeedStub =

On Oct 20, 2010, at 11:53 AM, Dan Gohman wrote: > > On Oct 19, 2010, at 8:00 PM, Jakob Stoklund Olesen wrote: >> >> >> One problem is that calling conventions are handled while building the selection DAG, and the DAG doesn't really know to represent clobbered registers. >> >> Perhaps X86TargetLowering::LowerCall() could decorate the X86ISD::CALL node

Great! Are there other issues I should be aware of? Félix Le 2010-11-25 à 07:43:23, Anton Korobeynikov a écrit : > Hello Felix > >> I have a project in mind that involves using the JIT for a few targets (x86 >> and x86_64 processors on Mac OS, Linux and Windows). However, there is an >> open bug that says LLVM generates incorrect code for Win64. >> Eli's last

Felix, > Great! Are there other issues I should be aware of? There might be some issues wrt tailcalls, but I'd not expect anything else to be major broken. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello list, i am currently trying to implement tail call optimization in the X86 backend , so far i have it working for cases (modulo many unknown bugs :) where the tail called function is a destination within the source file and frame pointer elimination is performed. i implemented it as a dagcombiner transformation running in post legalized phase within the

On Oct 19, 2010, at 8:00 PM, Jakob Stoklund Olesen wrote: > > > One problem is that calling conventions are handled while building the selection DAG, and the DAG doesn't really know to represent clobbered registers. > > Perhaps X86TargetLowering::LowerCall() could decorate the X86ISD::CALL node with the calling convention somehow? > > Dan, do you have any thoughts on

Hello, I am trying to insert a .byte/.word in the beginning of a specific LLVM IR instruction when it prints out in assembly (the inserted ‘instruction' only appears in assembly, not in LLVM IR), and I am guessing the best way to do that is to insert it in SelectionDAG as it strips down some LLVM IR instructions when it’s lowered. Can I get some guidance on what function I should use to insert