search for: machinereloc

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

...> > > --- lib/ExecutionEngine/JIT/JITEmitter.cpp      (original patch) > +++ lib/ExecutionEngine/JIT/JITEmitter.cpp      (my changes) > @@ -946,6 +947,7 @@ >   // FnEnd is the end of the function's machine code. >   uint8_t *FnEnd = CurBufferPtr; > > +  std::vector<MachineRelocation> BackupRelocations = Relocations; >   if (!Relocations.empty()) { >     CurFn = F.getFunction(); >     NumRelos += Relocations.size(); > @@ -1028,8 +1030,18 @@ >   MemMgr->endFunctionBody(F.getFunction(), BufferBegin, CurBufferPtr); > >   if (CurBufferPtr == BufferEn...

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

...>setCurrentPtr(CurBufferPtr); >> + return false; >> + } >> + virtual void startFunctionStub(unsigned StubSize, unsigned >> Alignment) {} >> + virtual void *finishFunctionStub(const Function *F) { return 0; } >> + virtual void addRelocation(const llvm::MachineRelocation&) { } >> + virtual void emitByte(unsigned char B) { >> + CurBufferPtr++; >> + } >> + virtual void emitWordLE(unsigned W) { >> + CurBufferPtr+=4; >> + } >> + virtual void emitWordBE(unsigned W) { >> + CurBufferPtr+=4; >> +...

...&F) { > + MCE->setCurrentPtr(CurBufferPtr); > + return false; > + } > + virtual void startFunctionStub(unsigned StubSize, unsigned > Alignment) {} > + virtual void *finishFunctionStub(const Function *F) { return 0; } > + virtual void addRelocation(const llvm::MachineRelocation&) { } > + virtual void emitByte(unsigned char B) { > + CurBufferPtr++; > + } > + virtual void emitWordLE(unsigned W) { > + CurBufferPtr+=4; > + } > + virtual void emitWordBE(unsigned W) { > + CurBufferPtr+=4; > + } > + virtual void emitInt32(in...

...ufferPtr); >>> + return false; >>> + } >>> + virtual void startFunctionStub(unsigned StubSize, unsigned >>> Alignment) {} >>> + virtual void *finishFunctionStub(const Function *F) { return 0; } >>> + virtual void addRelocation(const llvm::MachineRelocation&) { } >>> + virtual void emitByte(unsigned char B) { >>> + CurBufferPtr++; >>> + } >>> + virtual void emitWordLE(unsigned W) { >>> + CurBufferPtr+=4; >>> + } >>> + virtual void emitWordBE(unsigned W) { >>> +...

...gt; + return false; >>>> + } >>>> + virtual void startFunctionStub(unsigned StubSize, unsigned >>>> Alignment) {} >>>> + virtual void *finishFunctionStub(const Function *F) { return 0; } >>>> + virtual void addRelocation(const llvm::MachineRelocation&) { } >>>> + virtual void emitByte(unsigned char B) { >>>> + CurBufferPtr++; >>>> + } >>>> + virtual void emitWordLE(unsigned W) { >>>> + CurBufferPtr+=4; >>>> + } >>>> + virtual void emitWordBE(...

...t;>> + virtual void startFunctionStub(unsigned StubSize, unsigned >>>>>> Alignment) {} >>>>>> + virtual void *finishFunctionStub(const Function *F) { return >>>>>> 0; } >>>>>> + virtual void addRelocation(const llvm::MachineRelocation&) { } >>>>>> + virtual void emitByte(unsigned char B) { >>>>>> + CurBufferPtr++; >>>>>> + } >>>>>> + virtual void emitWordLE(unsigned W) { >>>>>> + CurBufferPtr+=4; >>>>>> +...

...virtual void startFunctionStub(unsigned StubSize, unsigned >>>>>>> Alignment) {} >>>>>>> + virtual void *finishFunctionStub(const Function *F) { return >>>>>>> 0; } >>>>>>> + virtual void addRelocation(const llvm::MachineRelocation&) >>>>>>> { } >>>>>>> + virtual void emitByte(unsigned char B) { >>>>>>> + CurBufferPtr++; >>>>>>> + } >>>>>>> + virtual void emitWordLE(unsigned W) { >>>>>>&g...

...+ } >>>>> + virtual void startFunctionStub(unsigned StubSize, unsigned >>>>> Alignment) {} >>>>> + virtual void *finishFunctionStub(const Function *F) { return >>>>> 0; } >>>>> + virtual void addRelocation(const llvm::MachineRelocation&) { } >>>>> + virtual void emitByte(unsigned char B) { >>>>> + CurBufferPtr++; >>>>> + } >>>>> + virtual void emitWordLE(unsigned W) { >>>>> + CurBufferPtr+=4; >>>>> + } >>>>>...

...rtFunctionStub(unsigned StubSize, unsigned >>>>>>>> Alignment) {} >>>>>>>> + virtual void *finishFunctionStub(const Function *F) { return >>>>>>>> 0; } >>>>>>>> + virtual void addRelocation(const llvm::MachineRelocation&) >>>>>>>> { } >>>>>>>> + virtual void emitByte(unsigned char B) { >>>>>>>> + CurBufferPtr++; >>>>>>>> + } >>>>>>>> + virtual void emitWordLE(unsigned W) { >&g...

Hello! Working with LLVM JIT-compiler I found a small bug and I'd like to correct it. Namely, on some tests LLVM fails with message "JIT: Ran out of space for generated machine code!" This error emerges because the test creates big static array. Global variables are placed into memory block for function, that is first seen using given variable. Besides, during memory allocation

...ind { entry: %call = 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...

...>>>>>> Alignment) {} >>>>>>>>> + virtual void *finishFunctionStub(const Function *F) >>>>>>>>> { return >>>>>>>>> 0; } >>>>>>>>> + virtual void addRelocation(const llvm::MachineRelocation&) >>>>>>>>> { } >>>>>>>>> + virtual void emitByte(unsigned char B) { >>>>>>>>> + CurBufferPtr++; >>>>>>>>> + } >>>>>>>>> + virtual void emitWordLE(un...

...uot;write" even when DlsymStub are disabled. If that's right, then the stub should be registered by AddStubToCurrentFunction(). If, on the other hand, we don't want stubs in such a case, then there is another problem elsewhere that turns the call to "write" into an incorrect MachineRelocation. Thanks, Eric. Index: lib/ExecutionEngine/JIT/JITEmitter.cpp =================================================================== --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 74506) +++ lib/ExecutionEngine/JIT/JITEmitter.cpp (working copy) @@ -658,9 +658,6 @@ } void JITEmitter::A...

Adding the different header files is not strictly required but certain features (Search in solution for example) in VS work better when they are there... m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050103/9de97790/attachment.txt>

...Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, November 25, 2008 1:51:35 AM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] MachineCodeEmitter Patch Thanks. But we need to match the type changes in all the target. e.g. ARMJITInfo.cpp, X86CodeEmitter.cpp. Also in MachineRelocation, e.g. getBB. Could you prepare a patch with all those fixed as well? Evan On Nov 22, 2008, at 1:19 PM, Thomas Jablin wrote: > Here is the corrected version. > > Thomas Jablin wrote: >> Actually, there is a problem with the patch. Please delay review. >> >> Thoma...

On Apr 12, 2006, at 10:23 PM, Simon Burton wrote: > > Is it possible to get llvm to generate native machine code > without using gcc and friends ? Do I use lli ? llc. llc --help lists all the options. it compiles llvm bytecode files. > > I'd like to directly create executable code that i can > stick in memory somewhere and jump into (call). > > (I'm looking

...Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, November 25, 2008 1:51:35 AM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] MachineCodeEmitter Patch Thanks. But we need to match the type changes in all the target. e.g. ARMJITInfo.cpp, X86CodeEmitter.cpp. Also in MachineRelocation, e.g. getBB. Could you prepare a patch with all those fixed as well? Evan On Nov 22, 2008, at 1:19 PM, Thomas Jablin wrote: > Here is the corrected version. > > Thomas Jablin wrote: >> Actually, there is a problem with the patch. Please delay review. >> >> Thoma...

...Simon. $ llc -filetype=dynlib -f -o=helloworld.so helloworld.bc llc: target 'X86' does not support generation of this file type! $ llc -filetype=obj -f -mcpu=i386 -march=x86 -o=helloworld.o helloworld.bc llc: ELFWriter.cpp:81: virtual void llvm::ELFCodeEmitter::addRelocation(const llvm::MachineRelocation&): Assertion `0 && "relo not handled yet!"' failed. llc((anonymous namespace)::PrintStackTrace()+0x1a)[0x8ac5736] llc((anonymous namespace)::SignalHandler(int)+0xed)[0x8ac59cb] [0xffffe420] /lib/tls/libc.so.6(abort+0x1d2)[0xb7dc7fa2] /lib/tls/libc.so.6(__assert_fail+0...