Displaying 8 results from an estimated 8 matches for "doesntneedstub".
2009 Jun 11
1
[LLVMdev] [unladen-swallow] Re: Why does the x86-64 JIT emit stubs for external calls?
...= tail call i32 @rand() ; <i32> [#uses=1]
%add = add i32 %call, 2 ; <i32> [#uses=1]
ret i32 %add
}
and the command line `lli -debug-only=jit -march=x86-64 test.bc`.
With lazy compilation and a call to an internal function, the
JITEmitter can emit a stub even if MachineRelocation::doesntNeedStub()
(the field NeedStub gets passed into) returns true. Only returning
false constrains the emitter.
> 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.
Oh, other t...
2005 Feb 20
3
[LLVMdev] HowToUseJIT: failed assertion on PPC/Mac OS X
...0x000123e4 in (anonymous
namespace)::JITResolver::getFunctionStub(llvm::Function*)
(this=0x70be78, F=0x5101010) at JITEmitter.cpp:184
#6 0x00012a48 in (anonymous
namespace)::JITEmitter::getPointerToGlobal(llvm::GlobalValue*, void*,
bool) (this=0x5101670, V=0x5101010, Reference=0x5685010,
DoesntNeedStub=false) at JITEmitter.cpp:334
#7 0x00012ccc in (anonymous
namespace)::JITEmitter::finishFunction(llvm::MachineFunction&)
(this=0x5101670, F=@0x51038c0) at JITEmitter.cpp:355
#8 0x00033fec in (anonymous
namespace)::PPC32CodeEmitter::runOnMachineFunction(llvm::
MachineFunction&) (this...
2009 Mar 09
0
[LLVMdev] Cross-Module Function Calls
...2
#3 0x00000000005651a9 in llvm::JIT::getPointerToFunction
(this=0x2d4bb80, F=0x2d45dd0) at JIT.cpp:538
#4 0x000000000056d3c5 in getFunctionStub (this=0x2d5a8b0, F=0x2d45dd0)
at JITEmitter.cpp:181
#5 0x000000000056d79a in getPointerToGlobal (this=0x2d5a820,
V=0x2d45dd0, Reference=0x7f25d605e01a, DoesntNeedStub=false) at
JITEmitter.cpp:632
#6 0x000000000056daba in finishFunction (this=0x2d5a820, F=@0x2d76b00)
at JITEmitter.cpp:924
#7 0x00000000006989ff in runOnMachineFunction (this=0x2d74900,
MF=@0x2d76b00) at X86CodeEmitter.cpp:118
#8 0x000000000043d1dd in llvm::MachineFunctionPass::runOnFunction
(thi...
2009 Jun 11
0
[LLVMdev] Why does the x86-64 JIT emit stubs for external calls?
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 ||
>
2009 Jun 10
3
[LLVMdev] Why does the x86-64 JIT emit stubs for external calls?
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;
2007 Dec 11
0
[LLVMdev] Exception handling in JIT
...EmitInt64(0);
> + EmitInt64(0);
> + } else {
> + EmitInt32(0);
> + EmitInt32(0);
> + }
> +
> +
> + return StartEHPtr;
> +}
> +
> +
> void *JITEmitter::getPointerToGlobal(GlobalValue *V, void *Reference,
> bool DoesntNeedStub) {
> if (GlobalVariable *GV = dyn_cast<GlobalVariable>(V)) {
> @@ -413,6 +1098,7 @@
> TheJIT->updateGlobalMapping(F.getFunction(), CurBufferPtr);
>
> MBBLocations.clear();
> + if (ExceptionHandling) DE->startFunction(F);
> }
>
> bool JITEmitter::fi...
2007 Dec 10
2
[LLVMdev] Exception handling in JIT
Hi everyone,
Here's a patch that enables exception handling when jitting. I've
copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need
to factorize it, but the functionality is there and I'm very happy with
it :)
lli should now be able to execute the output from llvm-gcc when using
exceptions (the UnwindInst instruction is not involved in this patch).
Just add the
2007 Jul 05
2
[LLVMdev] PATCH (rest of code changes) "bytecode" --> "bitcode"
Here is the bulk of the sanitizing.
My residual doubts center around the question
whether we still do/want to support (un)compressed *byte*code
in 2.0/2.1.
I need a definitive word on this to proceed.
My understanding is that bytecode is already gone, but there are
still some functions/enums that really deal with *byte*code
(instead of *bit*code).
I did not touch those areas, so the attached