[LLVMdev] code generation for calls in JITted code after r88984

[Jeffrey Yasskin]

On Tue, Dec 15, 2009 at 1:05 AM, Zoltan Varga <vargaz at gmail.com> wrote:
> Hi,
>
> After this commit:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=88984
>
> the X86 JIT no longer emits calls using call <ADDR>, but always uses mov
> REG, <ADDR>, call *REG.

That should only be the x86-64 JIT. If the x86-32 JIT does that, it's
definitely a bug. For x86-64, it's required unless the
JITMemoryManager can guarantee that it only allocates code within 2GB
of the text segment.

> This causes problems for the usage of LLVM in JITs
> since the JIT can no longer patch the callsite after the callee have been
> compiled.

As far as I know, the JIT only tries to patch the callsite when it's
compiling lazily. In that case, it uses X86JITInfo::emitFunctionStub()
to emit a stub with known layout that it can patch. It doesn't try to
patch the call to the stub.

If you've found a broken case here, could you send a (small!) test
program with its compilation line, or a patch to
http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/JIT/JITTest.cpp
that exposes it? English descriptions of these problems tend to be too
vague to reproduce.

> According to the comments for the commit, this was done to fix the
> large code model on amd64, but this affects JITs which can guarantee that
> both the caller and callee have 32 bit addresses, since the code model is
> set uncoditionally to Large, even if another code model was passed to
> createJIT ():

JIT::createJIT() intends to obey the CodeModel you pass it, but
someone else was complaining of a bug there too. The CodeModel is
definitely intended to be configurable, specifically so that users can
specify the guarantees their JITMemoryManager provides. Still, it's
supposed to be an optimization. The large code model should always
produce correct code.

>
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86TargetMachine.cpp?r1=86251&r2=88984&pathrev=88984
>
> Would it be possible to fix this or make it configurable ?
>
>                                thanks
>
>                                     Zoltan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>