search for: startfunctionbody

...not virtual in base class so we can't delegate. * Instead we mirror the value of HasGOT in our instance. */ HasGOT = mgr()->isManagingGOT(); } virtual uint8_t *getGOTBase() const { return mgr()->getGOTBase(); } virtual uint8_t *startFunctionBody(const llvm::Function *F, uintptr_t &ActualSize) { return mgr()->startFunctionBody(F, ActualSize); } virtual uint8_t *allocateStub(const llvm::GlobalValue *F, unsigned StubSize,...

...t farther and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) -matt Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () (gdb) where #0 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () #1 0x0000000100003ea0 in llvm::RuntimeDyldImpl::extractFunction () #2 0x00000001000059a5 in llvm::RuntimeDyldMachO::loadSegment64 () #3 0x000000010000493d in llvm::RuntimeDyldMachO::loadObject () #4 0x000000...

...can't delegate. > * Instead we mirror the value of HasGOT in our instance. > */ > HasGOT = mgr()->isManagingGOT(); > } > virtual uint8_t *getGOTBase() const { > return mgr()->getGOTBase(); > } > virtual uint8_t *startFunctionBody(const llvm::Function *F, > uintptr_t &ActualSize) { > return mgr()->startFunctionBody(F, ActualSize); > } > virtual uint8_t *allocateStub(const llvm::GlobalValue *F, > unsigned StubSiz...

...* Instead we mirror the value of HasGOT in our instance. >> */ >> HasGOT = mgr()->isManagingGOT(); >> } >> virtual uint8_t *getGOTBase() const { >> return mgr()->getGOTBase(); >> } >> virtual uint8_t *startFunctionBody(const llvm::Function *F, >> uintptr_t &ActualSize) { >> return mgr()->startFunctionBody(F, ActualSize); >> } >> virtual uint8_t *allocateStub(const llvm::GlobalValue *F, >>...

...ting ELFObject class for MCJIT to be able to run ELFs on ELF-platforms. One thing bothers me: I see that the RTDyldMemoryManager-based allocator is always passed to MCJIT and to RuntimeDyld classes from outside. This enforces the approach that memory will be allocated function by function with startFunctionBody/endFunctionBody. This maybe was good for the old JIT, but not for MCJIT. For ELF for example this isn't right. ELF is designed to be loaded into memory as a whole. I don't know much about MachO, but most likely it should be normally loaded into memory by OS in one block too, as a conse...

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

...*MJTI); >> void emitJumpTableInfo(MachineJumpTableInfo *MJTI); >> @@ -469,19 +476,47 @@ >> >> >> void JITEmitter::startFunction(MachineFunction &F) { >> - uintptr_t ActualSize; >> - BufferBegin = CurBufferPtr = MemMgr- >> >>> startFunctionBody(F.getFunction(), >>> >> - ActualSize); >> - BufferEnd = BufferBegin+ActualSize; >> + MMI->BeginFunction(&F); >> >> - // Ensure the constant pool/jump table info is at least 4-byte >&...

...void initJumpTableInfo(MachineJumpTableInfo *MJTI); > void emitJumpTableInfo(MachineJumpTableInfo *MJTI); > @@ -469,19 +476,47 @@ > > > void JITEmitter::startFunction(MachineFunction &F) { > - uintptr_t ActualSize; > - BufferBegin = CurBufferPtr = MemMgr- > >startFunctionBody(F.getFunction(), > - ActualSize); > - BufferEnd = BufferBegin+ActualSize; > + MMI->BeginFunction(&F); > > - // Ensure the constant pool/jump table info is at least 4-byte > aligned. > - emitAlignment(16); >...

...emitJumpTableInfo(MachineJumpTableInfo *MJTI); >>> @@ -469,19 +476,47 @@ >>> >>> >>> void JITEmitter::startFunction(MachineFunction &F) { >>> - uintptr_t ActualSize; >>> - BufferBegin = CurBufferPtr = MemMgr- >>> >>>> startFunctionBody(F.getFunction(), >>>> >>> - >>> ActualSize); >>> - BufferEnd = BufferBegin+ActualSize; >>> + MMI->BeginFunction(&F); >>> >>> - // Ensure the constant pool/jump table...

...t;> @@ -469,19 +476,47 @@ >>>> >>>> >>>> void JITEmitter::startFunction(MachineFunction &F) { >>>> - uintptr_t ActualSize; >>>> - BufferBegin = CurBufferPtr = MemMgr- >>>> >>>> >>>>> startFunctionBody(F.getFunction(), >>>>> >>>>> >>>> - >>>> ActualSize); >>>> - BufferEnd = BufferBegin+ActualSize; >>>> + MMI->BeginFunction(&F); >>>&gt...

...t;>> void JITEmitter::startFunction(MachineFunction &F) { >>>>>> - uintptr_t ActualSize; >>>>>> - BufferBegin = CurBufferPtr = MemMgr- >>>>>> >>>>>> >>>>>> >>>>>>> startFunctionBody(F.getFunction(), >>>>>>> >>>>>>> >>>>>>> >>>>>> - >>>>>> ActualSize); >>>>>> - BufferEnd = BufferBegin+ActualSize; >>>>>> + MMI->BeginFunction(&...

...han issuing that error. (Rebuilding with debugging symbols now to dig into it further…) > > -matt > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 > 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () > (gdb) where > #0 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () > #1 0x0000000100003ea0 in llvm::RuntimeDyldImpl::extractFunction () > #2 0x00000001000059a5 in llvm::RuntimeDyldMachO::loadSegment64 () > #3 0x000000010000493d in llvm::RuntimeDyldMachO::l...

Ah, now that makes sense. Guess I was a little over-eager with my bugreport. Thanks! :) However, I am now running into the same Problem as Matt ("Target does not support MC emission!"). Best, Ralf Am 25.08.2011 19:32, schrieb Bruno Cardoso Lopes: > Hi Ralf, > > FYI, old JIT doesn't support AVX at all, no encoding info, etc... The > only way to use AVX+JIT is using

...void JITEmitter::startFunction(MachineFunction &F) { >>>>>>> - uintptr_t ActualSize; >>>>>>> - BufferBegin = CurBufferPtr = MemMgr- >>>>>>> >>>>>>> >>>>>>> >>>>>>>> startFunctionBody(F.getFunction(), >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> - >>>>>>> ActualSize); >>>>>>> - BufferEnd = BufferBegin+ActualSize; >>>>>>> + MMI->Be...

...47 @@ >>>>> >>>>> >>>>> void JITEmitter::startFunction(MachineFunction &F) { >>>>> - uintptr_t ActualSize; >>>>> - BufferBegin = CurBufferPtr = MemMgr- >>>>> >>>>> >>>>>> startFunctionBody(F.getFunction(), >>>>>> >>>>>> >>>>> - >>>>> ActualSize); >>>>> - BufferEnd = BufferBegin+ActualSize; >>>>> + MMI->BeginFunction(&F); >>>>> >>>>> - // Ensure the c...

...gt;>>> - uintptr_t ActualSize; >>>>>>>> - BufferBegin = CurBufferPtr = MemMgr- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> startFunctionBody(F.getFunction(), >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> - >>>>>>>> ActualSize); >>>>>>>> -...

...ory block for function, that is first seen using given variable. Besides, during memory allocation for function its size is not considered in any way. Although there exist a code block (in JITEmitter::startFunction), which is able to calculate function size, allocator (in DefaultJITMemoryManager::startFunctionBody) does not consider predicted function size. So lli fails, when a test uses big static array. How would you advise to correct this bug? It is possible to allocate global variables in separate memory block(s) (in my opinion, it is not so good to place variables into executable memory area), or it...

Hi Ralf, FYI, old JIT doesn't support AVX at all, no encoding info, etc... The only way to use AVX+JIT is using MCJIT, which contains the correct encoding, but unfortunately the framework isn't good yet as the old one is. On Thu, Aug 25, 2011 at 10:12 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Matt, > > I am unsure about MCJIT, but I guess the problem is the same.

...>> - uintptr_t ActualSize; >>>>>>>>> - BufferBegin = CurBufferPtr = MemMgr- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> startFunctionBody(F.getFunction(), >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> - >>>>>>>>> ActualSize); >>>>>>>&...

On Dec 4, 2009, at 2:40 PM, Eric Christopher wrote: > So, on top of this it seems like a lot of the semantics have changed > after your patch. I'm certain the existing patch is wrong and that > we'll want a computation somewhat similar to the clang one that I > think Doug is going to post. > > I think the safe thing is to revert for now and we can discuss all