In my quest to account for memory, I've now come to the in-memory IR, and the generated code. I want to book the generated code memory against the agent that is generating the code. I see that LLVM's Function class [1] has a size function; what does this represent and can I use it to account for the space used by the in-memory IR? As for generated code, the JIT [2] class simply returns a "void *" when generating code for that function, with no size information that I can see. MachineCodeEmitter [3] is obtainable from the JIT class, and it contains "BufferBegin", "BufferEnd", and "CurBufferPtr" as protected members; if they were available, determining the generated code size might be possible via some pointer arithmetic. Is there another way I might be missing? Or would I have to subclass JITEmitter and add a method to perform this calculation? Finally, can I free the memory used by the in-memory IR after the code is generated? Sandro [1] http://llvm.org/doxygen/classllvm_1_1Function.html#a27 [2] http://llvm.org/doxygen/classllvm_1_1JIT.html [3] http://llvm.org/doxygen/classllvm_1_1MachineCodeEmitter.html
On Sep 28, 2007, at 10:27 AM, Sandro Magi wrote:> In my quest to account for memory, I've now come to the in-memory IR, > and the generated code. I want to book the generated code memory > against the agent that is generating the code. > > I see that LLVM's Function class [1] has a size function; what does > this represent and can I use it to account for the space used by the > in-memory IR?It returns the number of basic blocks in the function. Size on a basic block returns the number of instructions in it.> As for generated code, the JIT [2] class simply returns a "void *" > when generating code for that function, with no size information that > I can see.Right. If you pass -debug-only=jit to lli (before the bc file) it will print out the size of each function as it is compiled.> MachineCodeEmitter [3] is obtainable from the JIT class, and it > contains "BufferBegin", "BufferEnd", and "CurBufferPtr" as protected > members; if they were available, determining the generated code size > might be possible via some pointer arithmetic. Is there another way I > might be missing? Or would I have to subclass JITEmitter and add a > method to perform this calculation?You could do that, it will tell you the size of all of the machine code jit'd.> Finally, can I free the memory used by the in-memory IR after the code > is generated?Yes, you can call F->deleteBody() after JIT'ing F. -Chris> Sandro > > [1] http://llvm.org/doxygen/classllvm_1_1Function.html#a27 > [2] http://llvm.org/doxygen/classllvm_1_1JIT.html > [3] http://llvm.org/doxygen/classllvm_1_1MachineCodeEmitter.html > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 9/28/07, Chris Lattner <sabre at nondot.org> wrote:> > > MachineCodeEmitter [3] is obtainable from the JIT class, and it > > contains "BufferBegin", "BufferEnd", and "CurBufferPtr" as protected > > members; if they were available, determining the generated code size > > might be possible via some pointer arithmetic. Is there another way I > > might be missing? Or would I have to subclass JITEmitter and add a > > method to perform this calculation? > > You could do that, it will tell you the size of all of the machine > code jit'd.Right, unless I do it before and after jitting the new function and subtract them, in which case I'll get the size of the new function which I can then book to the agent.> > Finally, can I free the memory used by the in-memory IR after the code > > is generated? > > Yes, you can call F->deleteBody() after JIT'ing F.Sorry, I meant to ask whether it's still necessary to keep F around, ie. to delete generated code. Is there a standard approach to garbage collecting code in LLVM? Sandro
Apparently Analagous Threads
- [LLVMdev] Accounting for code size
- [LLVMdev] Accounting for code size
- [LLVMdev] [llvm-commits] Fwd: Re: [PATCH] Fix for bug in JIT exception table allocation
- [LLVMdev] Being able to know the jitted code-size before emitting
- [LLVMdev] Being able to know the jitted code-size before emitting