[llvm-commits] [PATCH] Make X86-64 in the Large model always emit 64-bit calls

[Evan Cheng]

Looks good. The only comment apart from Dan and Anton's comments is to  
force large code model for Darwin x86_64 as well unless explicitly  
specified otherwise.

Eric, please make sure large code model JIT works on Mac OS X.

Evan

On Nov 12, 2009, at 11:19 AM, jyasskin at gmail.com wrote:

> Reviewers: gohman_apple.com,
>
> Message:
> Patch at http://codereview.appspot.com/download/issue154066_1033.diff
>
> I'm unfamiliar with the code generator, so please go over that part of
> the change with a fine-toothed comb.
>
> This patch doesn't include r86941, assuming that'll be rolled back
> temporarily.
>
> Description:
> The large code model is documented at
> http://www.x86-64.org/documentation/abi.pdf and says that calls should
> assume their target doesn't live within the 32-bit pc-relative offset
> that fits in the call instruction.
>
> The best fix, turning off the global-address->target-global-address
> conversion in X86TargetLowering::LowerCall(), breaks the lazy JIT
> because it can separate the movabs(imm->reg) from the actual call
> instruction. The lazy JIT receives the address of the movabs as a
> relocation and needs to record the return address from the call; and
> then when that call happens, it needs to patch the movabs with the
> newly-compiled target. We could thread the call instruction into the
> relocation and record the movabs<->call mapping explicitly, but  that
> seems to require at least as much new complication in the code  
> generator
> as this change.
>
> The second attempt defined a new CALL64i pseudo-instruction, which
> expanded to a 2-instruction sequence in the assembly output and was
> special-cased in the X86CodeEmitter's emitInstruction() function. That
> breaks indirect calls, which stop using distinct stubs for each
> lazily-compiled function.
>
> The third attempt goes back to the first approach but makes lazy
> functions _always_ go through a call stub. This works. You'd think  
> we'd
> only have to force lazy calls through a stub on difficult platforms,  
> but
> that turns out to break indirect calls through a function pointer. The
> right fix for that is to distinguish between calls and address-of
> operations on uncompiled functions, but that's complex enough to leave
> for someone else to do.
>
> Please review this at http://codereview.appspot.com/154066
>
> Affected files:
>   M     lib/ExecutionEngine/JIT/JITEmitter.cpp
>   M     lib/Target/X86/X86CodeEmitter.cpp
>   M     lib/Target/X86/X86ISelLowering.cpp
>   M     lib/Target/X86/X86JITInfo.cpp
>   M     test/ExecutionEngine/stubs.ll
>   M     test/Makefile
>   M     unittests/ExecutionEngine/JIT/JITTest.cpp
>   M     utils/lit/TestFormats.py
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits