[llvm-commits] [PATCH] Reduce number of stubs used in 64bit code

[Jeffrey Yasskin]

In TargetJITInfo.h, s/advise/advice/ or s/has advise/advises/
s/Reference/CallerAddress/ and s/ResultPtr/TargetAddress/ and is there
a better name for MR? MR is just an in-parameter, right? In that case
it should be a const&, with a comment that MR.getResultPointer()
hasn't been filled in yet.

JITTest.cpp:
Alphabetize your new header, per
http://llvm.org/docs/CodingStandards.html#scf_includes

stop() is unused and shouldn't use std::cout anyway.

Instead of disassembling the output, it'd be really nice to look at
whether a stub was created directly. You should be able to do that by
creating your own JITMemoryManager.

Instead of FunctionType::get(Type::getInt32Ty(context), params,
false);, use TypeBuilder<int(), false>::get(context).

You probably don't need to MemMgr->setPoisonMemory(true); for this test.


X86JITInfo.cpp:

grammar: "code located at Callsite call Callee directly"


JITEmitter.cpp:

grammar: "The CodeGen has indicates"



Otherwise, looks good to me.

On Tue, Sep 1, 2009 at 2:34 PM, Evan Phoenix <evan at fallingsnow.net> wrote:
> Currently the JIT running on a x86_64 platform can only call an external
> function through a stub. This is because of a conservative decision about
> how the encoding of a pc-relative address would should up in the machine
> code stream. These stubs incur a penalty, so any stubs that can be
> eliminated should be.
>
> The attached patch allows the JITEmitter to override the CodeGen's decision
> to use a stub by validating if a stub is actually needed. Thus any calling
> functions who's pc-relative offset fits directly in a call instruction are
> used the same as they would on a 32bit platform.
>
> "Long" calls are still done via the stub mechanism.
>
> This only effects the calling of externally defined functions. It changes
> nothing with regard to lazy/future JIT'd LLVM functions.
>
> Thanks,
>
>  - Evan Phoenix
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>