[LLVMdev] Why does the x86-64 JIT emit stubs for external calls?

[Aaron Gray]

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

Aaron

>> 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?
>>
>> Thanks,
>> Jeffrey
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev