similar to: [LLVMdev] JIT Stub Problem

I'm having an issue with the Stubs used by the JIT Compiler. I'm not sure if it's a bug or if I'm doing something incorrectly. I've got a long complicated function with the following basic blocks at the end of it (The complete .ll file is attached): falseBlock: ; preds = %__exp.exit340 ret int 617 codeRepl: ; preds = %__exp.exit340

Hi All, Can anyone explain why the MachineRelocation field "NeedsStub" is set to true for GlobalValues on x86_64, but false on plain x86? This is causing the JITEmitter to allocate a stub for every GlobalValue relocation it encounters on x86_64, quickly exhausting the 512K region for stubs in the default JIT memory manager. Is this expected behavior? Is there anyway to override the stub

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

On Thu, Jun 11, 2009 at 12:54 PM, Evan Cheng<evan.cheng at apple.com> wrote: > > > > 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 =

I'm having an issue with the CodeExtractor. When I try to extract the lone basic block from the following function, I get an assertion error. define i32 @test(i32 %x) { %tmp = call i32 @test3( i32 %x ) ; <i32> [#uses=1] ret i32 %tmp } The assertion error is: lli: Dominators.cpp:71: void llvm::DominatorTree::splitBlock(llvm::BasicBlock*): Assertion

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;

I sent a long message yesterday describing a problem I thought had to do with the JIT stubs. After further investigating, the problem seems to be in the code generation. The following basic block seems to have an error in it's code generation: __exp.exit: ; preds = %codeRepl258, %__exp_bb_bb.exit phi double [ 1.000000e+00, %codeRepl258 ], [ %.reload.reload.i,

Hi! It appeared to me that runFunction in JIT.cpp is slow for repeatedly executing the same function with nontrivial arguments since the "Stub" function in JiT.cpp:183 (LLVM 1.9) is compiled again and again. Is there something I can do to accelerate this? g

Hi Lang, That would be great ! :) For now I found a hack which consist of loading a "full of NOP" DLL, use my own DllMemMgr which allocates JIT sections inside the DLL virtual space, backup the memory inside some buffers, unload the DLL, copy the buffer inside the DLL file, create the PDB, reload the DLL file which hopefully in 99% is reloaded at the same virtual address (this allow me

Sorry I meant 0xE8, 0xFF was in my head because of disassembling and seeing it in use, my bad. Ok I didn't thought about PIC, that's a good idea ! ... I forgot it existed at the wrong moment I guess ... How can I modify the GOT then ? Is there an api somewhere in the execution engine / MCJIT ? Or is it somewhere else ? Or I need to accept the idea of hacking stuff inside the LLVM code

Hi all, I am new to LLVM so I apologize if my question seem lame to you. I was trying to understand the way in which MCJIT generates the stub functions when it encounters any functions which are not compiled yet. As far as I have looked into the code, the probable code which can do this is void *JIT::getPointerToFunctionOrStub and this is in JITEmitter under JIT. I may be wrong here though.

Hi, Before I go ahead and remove the generation of stubs for external functions, is there any good reason why they get generated? I can understand that the JIT wants to make stubs for the functions it compiles itself - it enables selective recompilation and replacement - but functions which are defined in a library (or in my case by the application using the JIT) can't be changed anyway.

Hi Andy, I have been following Julia with interest, as it's a type-optional language designed to be as nice as dynamic languages but run at the speed of compiled C++ programs. They achieve this by deducing as many types at compile time and JITing code for the unknown types at runtime when they are known. That's a smart use of a JIT. In C++ terms it's analog to instantiating templates

Commit-ID: 6e2976b9d103fb37a6a06e5bccb323fa5ab1c53b Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=6e2976b9d103fb37a6a06e5bccb323fa5ab1c53b Author: Mauricio Faria de Oliveira <mauricfo at linux.vnet.ibm.com> AuthorDate: Wed, 6 Jan 2016 00:43:10 +0000 Committer: H. Peter Anvin <hpa at linux.intel.com> CommitDate: Tue, 5 Jan 2016 17:45:31 -0800 [klibc] ppc64:

Hi Andy, We had previous discussions about this, I'd like to state more exactly what features would make MCJIT a replacement for the JIT. After putting significant effort trying to move to MCJIT, I'm currently back with the JIT. This is in a REPL environment where functions are added and removed dynamically and response time is important. The issue is the legacy JIT provides great

Hi Yaron, I think a lot of what I said in my reply to Gaël also applies to your situation. In particular, I think that it's probably best for your code to manager the function stubs and replacement. I talked last week with a developer who works on the Julia language (which shares a lot of features your situation) and it's my understanding that the Julia runtime handles function stubs

Hi Gaël, I'm not familiar enough with the details of the old JIT engine and its event interface to comment on whether or not your changes are appropriate, but I'm not sure anyone is so the patch is probably OK as is. I don't see any obvious problems with it. However, your description of the changes raises a bigger issue in my mind. I'm not sure if you are aware of this, but

I'm using Xapian 1.0.8 and the python bindings. I have a flint database which I can open fine by doing the following: db_name = '/path/to/db/db-name' database = xapian.WritableDatabase(db_name, xapian.DB_OPEN) However, if I have stub file at '/path/to/db/db-stub' containing the following: flint /path/to/db/db-name db_name = '/path/to/db/db-stub' database =

----- Original Message ----- From: "Nicolas Geoffray" <nicolas.geoffray at lip6.fr> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Wednesday, November 07, 2007 10:03 AM Subject: Re: [LLVMdev] Dynamic (JIT) type resolution > BGB wrote: >> maybe a tradeoff is possible: >> the function to get the offset is replaced by a function

We have a test that has been working find until we upgraded to rails 2.3.5. I''m not too familiar with mocks/stubs so maybe there is an easy solution. Here is a simple example of our scenario. Class Person < ActiveRecord::Base has_many :aliases, :dependent => :nullify before_destroy :mark_aliases_as_deleted def mark_aliases_as_deleted self.aliases.each do