search for: jitemitt

Displaying 20 results from an estimated 163 matches for "jitemitt".

Did you mean: jitemitter
2009 Feb 28
2
[LLVMdev] Removal of GVStub methods from MachineCodeEmitter, ELFWriter, and MachOWriter
...ific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dependance on MachineCodeEmitter and the GVStub methods. Also the fact that JITEmitter is hidden and quite a large class in a .cpp file. At first I did this by introducing a JITCodeEmitter class between MachineCodeEmitter and the (un)hidden JITEmitter. But this lead to more dependancies and they lead on to more. I have now made class header for JITEmitter putting it in the llvm n...
2009 Mar 02
0
[LLVMdev] Removal of GVStub methods from MachineCodeEmitter, ELFWriter, and MachOWriter
...lowing comments :- > > /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! > > To get rid of these easily turned out to be a semicomplex > modification because of the JITInfo classes dependance on > MachineCodeEmitter and the GVStub methods. Also the fact that > JITEmitter is hidden and quite a large class in a .cpp file. > > At first I did this by introducing a JITCodeEmitter class between > MachineCodeEmitter and the (un)hidden JITEmitter. But this lead to > more dependancies and they lead on to more. > > I have now made class header for JIT...
2008 Oct 15
0
[LLVMdev] bug in the JIT global variable emitter
...> (i.e. > when dumping a global variable out of the scope of a function > compilation). > The patch is at: > http://web.ist.utl.pt/nuno.lopes/llvm_jit_global_emitter2.txt OK, I think I finally understand this: the allocation in JIT::getOrEmitGlobalVariable doesn't call into JITEmitter but uses the MachineCodeEmitter directly. Thus, if you call it from outside the JITEmitter, it won't update the data structures the JITEmitter relies on. In the usual case, the JITEmitter calls into JIT and updates its own data structures, so that case works fine. I think adding a...
2009 Jul 01
0
[LLVMdev] [PATCH][RFC] Bug #4406: stubs for external functions should be registered even if DlsymStubs are disabled
...to be updated to free the machine code with: ee->freeMachineCodeForFunction(cast<Function>(ll_main)); Once that's done, though, the AssertingVH is still triggered on destruction of the Module. It turns out that the stub for the external "write" is not registered by JITEmitter::AddStubToCurrentFunction() because DlsymStubs are not enabled. void JITEmitter::AddStubToCurrentFunction(void *StubAddr) { if (!TheJIT->areDlsymStubsEnabled()) return; It seems wrong. From include/llvm/ExecutionEngine/JITMemoryManager.h, my understanding is that DlsymStubs are only...
2008 Oct 16
2
[LLVMdev] bug in the JIT global variable emitter
...umping a global variable out of the scope of a function >> compilation). >> The patch is at: >> http://web.ist.utl.pt/nuno.lopes/llvm_jit_global_emitter2.txt > > OK, I think I finally understand this: the allocation in > JIT::getOrEmitGlobalVariable doesn't call into JITEmitter but uses the > MachineCodeEmitter directly. Thus, if you call it from outside the > JITEmitter, it won't update the data structures the JITEmitter relies > on. In the usual case, the JITEmitter calls into JIT and updates its > own data structures, so that case works fine. exac...
2008 Oct 14
2
[LLVMdev] bug in the JIT global variable emitter
>> Today I found a nice bug in the JIT global variable emitter. >> The problem may lead to an assert() failure when doing the following: >> 1) compile some function >> 2) emit a global variable >> 3) compile another function. an assert() may trigger in the JIT memory >> manager >> >> This happens because the JIT global variable emitter is using the
2014 Mar 21
3
[LLVMdev] lli crashes when running cpp programs
...nto the problem and find that it is caused by the alias instructions: @_ZN3clsC1Ev = alias void (%class.cls*)* @_ZN3clsC2Ev @_ZN3clsD1Ev = alias void (%class.cls*)* @_ZN3clsD2Ev The first alias is for the constructor and the other one is for the destructor. When finishing JIT the main function, JITEmitter needs to resolve all the names in main. When it is trying to resolve the alias name @_ZN3clsC1Ev, the following code in JITEmitter.cpp will go to resolve and JIT the original name of the alias name. In my case, they are @_ZN3clsC2Ev and @_ZN3clsD2Ev. This procedure will cause a recursive compilat...
2010 Feb 26
1
[LLVMdev] 2nd attempt for a working patch for bug 2606
...ch. > > I must say that I largely prefer this version over the previous one ! I > like the reuse of getLazyFunctionStub, but I don't know if the > forceEmitFunctionStub is still needed ? > > > JIT::forceEmitFunctionStub(...) was created to bring its implementation > into JITEmitter file scope as JITResolver and > therefore JITResolver::getLazyFunctionStub(...) are members of an anonymous > namespace in that scope. However > I can instead use a pre-existing method: getPointerToFunctionOrStub(...) > which is declared in ExecutionEngine > and overwritten in JIT...
2004 Dec 14
0
[LLVMdev] misc. patches
...ystem memory and a minor modification to > how one particular singleton object gets instantiated in CommandLine.cpp > to stop the VS leak detector complaining. > > m. > > ______________________________________________________________________ > Index: lib/ExecutionEngine/JIT/JITEmitter.cpp > =================================================================== > RCS file: /var/cvs/llvm/llvm/lib/ExecutionEngine/JIT/JITEmitter.cpp,v > retrieving revision 1.59 > diff -u -r1.59 JITEmitter.cpp > --- lib/ExecutionEngine/JIT/JITEmitter.cpp 5 Dec 2004 07:19:16 -0000 1.59 &...
2008 Oct 16
0
[LLVMdev] bug in the JIT global variable emitter
...out of the scope of a function >>> compilation). >>> The patch is at: >>> http://web.ist.utl.pt/nuno.lopes/llvm_jit_global_emitter2.txt >> >> OK, I think I finally understand this: the allocation in >> JIT::getOrEmitGlobalVariable doesn't call into JITEmitter but uses >> the >> MachineCodeEmitter directly. Thus, if you call it from outside the >> JITEmitter, it won't update the data structures the JITEmitter relies >> on. In the usual case, the JITEmitter calls into JIT and updates >> its >> own data stru...
2004 Dec 13
6
[LLVMdev] misc. patches
Hi, here are some minor patches that for various reasons I've not submitted yet - I'm just trying to clear my list of differences before christmas... First of all the clear.patch file contains a patch that enables the JIT to drop all global mappings. I need this because when I have N threads I compile N different versions of my functions using different memory areas for global
2011 Apr 19
0
[LLVMdev] Crash in llvm::JITDwarfEmitter::EmitDwarfTable on 2.8 and 2.9 release but not on trunk?
I found the problem : my code sets JITEmitDebugInfo after creating the JIT. This causes the JITDwarfEmitter DE to not be constructed in the ctor of JITEmitter (JITEmitter.cpp around line 375). Not sure if it's documented anywhere that JITEmitDebugInfo must be set before constructing the JIT, but looking at the code, it makes sense. Easy enough to fix on my side. Christophe On 19 avr. 2011, at 17:38, Christophe de Dinechin wrote: > Hello, &g...
2011 Apr 19
2
[LLVMdev] Crash in llvm::JITDwarfEmitter::EmitDwarfTable on 2.8 and 2.9 release but not on trunk?
...ot access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x0000000100852203 in llvm::JITDwarfEmitter::EmitDwarfTable () at context.h:491 (gdb) bt #0 0x0000000100852203 in llvm::JITDwarfEmitter::EmitDwarfTable () at context.h:491 #1 0x0000000100859a76 in (anonymous namespace)::JITEmitter::finishFunction () at context.h:491 #2 0x0000000100871a6a in (anonymous namespace)::Emitter<llvm::JITCodeEmitter>::runOnMachineFunction () at stl_tree.h:1050 #3 0x0000000100b1381d in llvm::MachineFunctionPass::runOnFunction () at stl_tree.h:1050 #4 0x0000000100ee15f0 in llvm::FPPassManag...
2012 Sep 24
0
[LLVMdev] [llvm-commits] Fwd: Re: [PATCH] Fix for bug in JIT exception table allocation
Pinging again, more loudly :-) Michael Muller wrote: > > Ping. (looking for someone to review or commit this, thanks) > > Michael Muller wrote: > > > > Thanks, Duncan - > > > > > Hi Michael, > > > > > > > --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 163478) > > > > +++ lib/ExecutionEngine/JIT/JITEmitter.cpp (working copy) > > > > @@ -974,14 +974,24 @@ > > > > SavedBufferBegin = BufferBegin; > > > > SavedBufferEnd = BufferEnd; > > > > SavedCurBufferPtr...
2005 Feb 20
3
[LLVMdev] HowToUseJIT: failed assertion on PPC/Mac OS X
...lvm::Function*) (this=0x51015c0, F=0x5101010) at JIT.cpp:217 #4 0x00011da4 in llvm::JIT::getPointerToFunction(llvm::Function*) (this=0x51015c0, F=0x5101010) at JIT.cpp:261 #5 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::Machine...
2010 Feb 26
0
[LLVMdev] 2nd attempt for a working patch for bug 2606
...h your patch. >> >> I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ? > > JIT::forceEmitFunctionStub(...) was created to bring its implementation into JITEmitter file scope as JITResolver and > therefore JITResolver::getLazyFunctionStub(...) are members of an anonymous namespace in that scope. However > I can instead use a pre-existing method: getPointerToFunctionOrStub(...) which is declared in ExecutionEngine > and overwritten in JIT (within J...
2010 Feb 26
2
[LLVMdev] 2nd attempt for a working patch for bug 2606
...take time to watch your patch. > > I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ? JIT::forceEmitFunctionStub(...) was created to bring its implementation into JITEmitter file scope as JITResolver and therefore JITResolver::getLazyFunctionStub(...) are members of an anonymous namespace in that scope. However I can instead use a pre-existing method: getPointerToFunctionOrStub(...) which is declared in ExecutionEngine and overwritten in JIT (within JITEmitter file...
2008 Mar 30
3
[LLVMdev] Being able to know the jitted code-size before emitting
Hi everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas --------------
2008 Apr 01
2
[LLVMdev] Being able to know the jitted code-size before emitting
...@ -31,6 +31,7 @@ >> bool UseSoftFloat; >> bool NoZerosInBSS; >> bool ExceptionHandling; >> + bool SizedMemoryCode; >> Reloc::Model RelocationModel; >> CodeModel::Model CMModel; >> bool PerformTailCallOpt; >> Index: lib/ExecutionEngine/JIT/JITEmitter.cpp >> =================================================================== >> --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 48143) >> +++ lib/ExecutionEngine/JIT/JITEmitter.cpp (working copy) >> @@ -18,12 +18,14 @@ >> #include "llvm/Constant.h" >&...
2008 Mar 31
0
[LLVMdev] Being able to know the jitted code-size before emitting
...achine.cpp (working copy) > @@ -31,6 +31,7 @@ > bool UseSoftFloat; > bool NoZerosInBSS; > bool ExceptionHandling; > + bool SizedMemoryCode; > Reloc::Model RelocationModel; > CodeModel::Model CMModel; > bool PerformTailCallOpt; > Index: lib/ExecutionEngine/JIT/JITEmitter.cpp > =================================================================== > --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 48143) > +++ lib/ExecutionEngine/JIT/JITEmitter.cpp (working copy) > @@ -18,12 +18,14 @@ > #include "llvm/Constant.h" > #include "llvm/...