[LLVMdev] Why does the x86-64 JIT emit stubs for external calls?
aaronngray.lists at googlemail.com
Thu Jun 11 17:56:21 PDT 2009
> 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
>> bool NeedStub =
>> (Is64BitMode &&
>> (TM.getCodeModel() == CodeModel::Large ||
>> TM.getSubtarget<X86Subtarget>().isTargetDarwin())) ||
>> Opcode == X86::TAILJMPd;
>> emitGlobalAddress(MO.getGlobal(), X86::reloc_pcrel_word,
>> MO.getOffset(), 0, NeedStub);
>> This causes every external call to be emitted as a call to a stub
>> which then jumps to the real function.
>> I understand, thanks to the helpful folks on #llvm, that calls across
>> more than 31 bits of address space need to be emitted as a "mov
>> $ADDRESS, r10; call *r10" pair instead of the simple "call
>> rip+ADDRESS" used for calls within 31 bits. But why isn't the mov+call
>> pair emitted inline? And why are Darwin and TAILJMPs special?
> This is needed because of lazy compilation, before the callee is
> resolved, it is just a JIT stub. It's heap allocated so it may not be
> in the lower 4G even if the code size model is small. I know this is
> the case on Darwin x86_64, I am not sure about other targets. I forgot
> why this is needed for tail calls, sorry.
> In theory we can make the code generator inline mov+call, the reality
> is it doesn't know whether it's jitting or not. Also, we really want
> to keep the code generation the same (as much as possible) whether
> it's jitting or compiling. One possible solution for this is to add
> code size model specifically for JIT so code generator can generate
> more efficient code in that configuration.
Since the CodeEmitter's are now generically parameterized they can be
specialized for JIT quite easily now.
>> Having this out of line seems to lose up to 2% performance on the
>> Unladen Swallow benchmarks, so, while it's not urgent, it'd be nice to
>> figure out how to avoid the stubs.
>> What kind of patch would be welcome to fix this?
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev