search for: bufferend

Displaying 20 results from an estimated 51 matches for "bufferend".

Did you mean: buffered
2008 Nov 22
2
[LLVMdev] MachineCodeEmitter Patch
...<stdio.h> char bigArray[0x1000000]; int main(int argc, char **argv) { printf("mem: 0x%x\n", (unsigned) bigArray); return 0; } causes lli to silently fail, even though it compiles correctly with llc. The reason is that in JITEmitter.cpp only checks to see if CurBufferPtr == BufferEnd at the beginning of the function and not after all relocations have been handled. I have fixed this bug by adding an additional check after all relocations have been completed. In the process of fixing this bug, I happened to look through the code in MachineCodeEmitter.h. The buffer size check...
2008 Nov 22
3
[LLVMdev] MachineCodeEmitter Patch
...c, char **argv) { >> printf("mem: 0x%x\n", (unsigned) bigArray); >> return 0; >> } >> >> causes lli to silently fail, even though it compiles correctly with >> llc. The reason is that in JITEmitter.cpp only checks to see if >> CurBufferPtr == BufferEnd at the beginning of the function and not >> after all relocations have been handled. I have fixed this bug by >> adding an additional check after all relocations have been completed. >> In the process of fixing this bug, I happened to look through the code >> in MachineC...
2012 Sep 24
0
[LLVMdev] [llvm-commits] Fwd: Re: [PATCH] Fix for bug in JIT exception table allocation
...gt; > > > > > --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 163478) > > > > +++ lib/ExecutionEngine/JIT/JITEmitter.cpp (working copy) > > > > @@ -974,14 +974,24 @@ > > > > SavedBufferBegin = BufferBegin; > > > > SavedBufferEnd = BufferEnd; > > > > SavedCurBufferPtr = CurBufferPtr; > > > > + uint8_t *FrameRegister; > > > > > > > > - BufferBegin = CurBufferPtr = > > > > MemMgr->startExceptionTable(F.getFunction(), > > > > -...
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
...ool; >> + MachineJumpTableInfo *JumpTable; >> + std::vector<intptr_t> LabelLocations; >> + MachineCodeEmitter* MCE; >> + >> +public: >> + SizeEmitter(MachineCodeEmitter* mce) { >> + CurBufferPtr = 0; >> + BufferBegin = 0; >> + BufferEnd = (unsigned char*)-1; >> + MCE = mce; >> + } >> + >> + SizeEmitter(std::vector<intptr_t> locations) { >> + LabelLocations = locations; >> + CurBufferPtr = 0; >> + BufferBegin = 0; >> + BufferEnd = (unsigned char*)-1; >> +...
2008 Mar 31
0
[LLVMdev] Being able to know the jitted code-size before emitting
...t; + MachineConstantPool *ConstantPool; > + MachineJumpTableInfo *JumpTable; > + std::vector<intptr_t> LabelLocations; > + MachineCodeEmitter* MCE; > + > +public: > + SizeEmitter(MachineCodeEmitter* mce) { > + CurBufferPtr = 0; > + BufferBegin = 0; > + BufferEnd = (unsigned char*)-1; > + MCE = mce; > + } > + > + SizeEmitter(std::vector<intptr_t> locations) { > + LabelLocations = locations; > + CurBufferPtr = 0; > + BufferBegin = 0; > + BufferEnd = (unsigned char*)-1; > + } > + > + void initConstantP...
2008 Nov 22
0
[LLVMdev] MachineCodeEmitter Patch
...; > > int main(int argc, char **argv) { > printf("mem: 0x%x\n", (unsigned) bigArray); > return 0; > } > > causes lli to silently fail, even though it compiles correctly with > llc. The reason is that in JITEmitter.cpp only checks to see if > CurBufferPtr == BufferEnd at the beginning of the function and not > after all relocations have been handled. I have fixed this bug by > adding an additional check after all relocations have been completed. > In the process of fixing this bug, I happened to look through the code > in MachineCodeEmitter.h. T...
2008 Apr 01
0
[LLVMdev] Being able to know the jitted code-size before emitting
...eInfo *JumpTable; >>> + std::vector<intptr_t> LabelLocations; >>> + MachineCodeEmitter* MCE; >>> + >>> +public: >>> + SizeEmitter(MachineCodeEmitter* mce) { >>> + CurBufferPtr = 0; >>> + BufferBegin = 0; >>> + BufferEnd = (unsigned char*)-1; >>> + MCE = mce; >>> + } >>> + >>> + SizeEmitter(std::vector<intptr_t> locations) { >>> + LabelLocations = locations; >>> + CurBufferPtr = 0; >>> + BufferBegin = 0; >>> + BufferEnd =...
2008 Apr 04
3
[LLVMdev] Being able to know the jitted code-size before emitting
...t; + std::vector<intptr_t> LabelLocations; >>>> + MachineCodeEmitter* MCE; >>>> + >>>> +public: >>>> + SizeEmitter(MachineCodeEmitter* mce) { >>>> + CurBufferPtr = 0; >>>> + BufferBegin = 0; >>>> + BufferEnd = (unsigned char*)-1; >>>> + MCE = mce; >>>> + } >>>> + >>>> + SizeEmitter(std::vector<intptr_t> locations) { >>>> + LabelLocations = locations; >>>> + CurBufferPtr = 0; >>>> + BufferBegin = 0; &...
2008 Apr 05
2
[LLVMdev] Being able to know the jitted code-size before emitting
...t;>>>> + MachineCodeEmitter* MCE; >>>>>> + >>>>>> +public: >>>>>> + SizeEmitter(MachineCodeEmitter* mce) { >>>>>> + CurBufferPtr = 0; >>>>>> + BufferBegin = 0; >>>>>> + BufferEnd = (unsigned char*)-1; >>>>>> + MCE = mce; >>>>>> + } >>>>>> + >>>>>> + SizeEmitter(std::vector<intptr_t> locations) { >>>>>> + LabelLocations = locations; >>>>>> + CurBufferP...
2008 Dec 08
0
[LLVMdev] MachineCodeEmitter Patch
...t; printf("mem: 0x%x\n", (unsigned) bigArray); >>> return 0; >>> } >>> >>> causes lli to silently fail, even though it compiles correctly >>> with llc. The reason is that in JITEmitter.cpp only checks to see >>> if CurBufferPtr == BufferEnd at the beginning of the function and >>> not after all relocations have been handled. I have fixed this bug >>> by adding an additional check after all relocations have been >>> completed. In the process of fixing this bug, I happened to look >>> through...
2008 Apr 05
0
[LLVMdev] Being able to know the jitted code-size before emitting
...chineCodeEmitter* MCE; >>>>>>> + >>>>>>> +public: >>>>>>> + SizeEmitter(MachineCodeEmitter* mce) { >>>>>>> + CurBufferPtr = 0; >>>>>>> + BufferBegin = 0; >>>>>>> + BufferEnd = (unsigned char*)-1; >>>>>>> + MCE = mce; >>>>>>> + } >>>>>>> + >>>>>>> + SizeEmitter(std::vector<intptr_t> locations) { >>>>>>> + LabelLocations = locations; >>>>>...
2008 Apr 04
0
[LLVMdev] Being able to know the jitted code-size before emitting
...t> LabelLocations; >>>>> + MachineCodeEmitter* MCE; >>>>> + >>>>> +public: >>>>> + SizeEmitter(MachineCodeEmitter* mce) { >>>>> + CurBufferPtr = 0; >>>>> + BufferBegin = 0; >>>>> + BufferEnd = (unsigned char*)-1; >>>>> + MCE = mce; >>>>> + } >>>>> + >>>>> + SizeEmitter(std::vector<intptr_t> locations) { >>>>> + LabelLocations = locations; >>>>> + CurBufferPtr = 0; >>>>...
2008 Apr 07
2
[LLVMdev] Being able to know the jitted code-size before emitting
...gt;>>>>>>> + >>>>>>>> +public: >>>>>>>> + SizeEmitter(MachineCodeEmitter* mce) { >>>>>>>> + CurBufferPtr = 0; >>>>>>>> + BufferBegin = 0; >>>>>>>> + BufferEnd = (unsigned char*)-1; >>>>>>>> + MCE = mce; >>>>>>>> + } >>>>>>>> + >>>>>>>> + SizeEmitter(std::vector<intptr_t> locations) { >>>>>>>> + LabelLocations = locations;...
2008 Dec 08
1
[LLVMdev] MachineCodeEmitter Patch
...t; printf("mem: 0x%x\n", (unsigned) bigArray); >>> return 0; >>> } >>> >>> causes lli to silently fail, even though it compiles correctly >>> with llc. The reason is that in JITEmitter.cpp only checks to see >>> if CurBufferPtr == BufferEnd at the beginning of the function and >>> not after all relocations have been handled. I have fixed this bug >>> by adding an additional check after all relocations have been >>> completed. In the process of fixing this bug, I happened to look >>> through...
2008 Apr 07
0
[LLVMdev] Being able to know the jitted code-size before emitting
...gt;>> + >>>>>>>>> +public: >>>>>>>>> + SizeEmitter(MachineCodeEmitter* mce) { >>>>>>>>> + CurBufferPtr = 0; >>>>>>>>> + BufferBegin = 0; >>>>>>>>> + BufferEnd = (unsigned char*)-1; >>>>>>>>> + MCE = mce; >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> + SizeEmitter(std::vector<intptr_t> locations) { >>>>>>>>> + LabelLoc...
2007 Dec 11
0
[LLVMdev] Exception handling in JIT
...> + > +class Function; > +class MachineCodeEmitter; > +class TargetData; > +class TargetMachine; > +class MachineFunction; > +class MachineModuleInfo; > +class MachineMove; > +class MRegisterInfo; > + > +class DwarfEmitter { > +protected: > + /// BufferBegin/BufferEnd - Pointers to the start and end of the > memory > + /// allocated for this code buffer. > + unsigned char *BufferBegin, *BufferEnd; > + > + /// CurBufferPtr - Pointer to the next byte of memory to fill > when emitting > + /// code. This is guranteed to be in the range...
2007 Dec 12
3
[LLVMdev] Exception handling in JIT
...s MachineCodeEmitter; >> +class TargetData; >> +class TargetMachine; >> +class MachineFunction; >> +class MachineModuleInfo; >> +class MachineMove; >> +class MRegisterInfo; >> + >> +class DwarfEmitter { >> +protected: >> + /// BufferBegin/BufferEnd - Pointers to the start and end of the >> memory >> + /// allocated for this code buffer. >> + unsigned char *BufferBegin, *BufferEnd; >> + >> + /// CurBufferPtr - Pointer to the next byte of memory to fill >> when emitting >> + /// code. This is g...
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
2008 Dec 05
0
[LLVMdev] MachineCodeEmitter Patch
...t; printf("mem: 0x%x\n", (unsigned) bigArray); >>> return 0; >>> } >>> >>> causes lli to silently fail, even though it compiles correctly >>> with llc. The reason is that in JITEmitter.cpp only checks to see >>> if CurBufferPtr == BufferEnd at the beginning of the function and >>> not after all relocations have been handled. I have fixed this bug >>> by adding an additional check after all relocations have been >>> completed. In the process of fixing this bug, I happened to look >>> through...