That sounds rather cumbersome, is there no simpler way to get the actual size of a struct? John Criswell wrote:> > Nyx wrote: >> Hello, >> >> I would just like to ask if it's possible to explicitly free allocas. >> This >> is because I need to call functions that take structs of different sizes >> as >> input, (possibly inside of loops) and I would rather avoid a stack >> overflow. >> > No, it's not legal to free memory returned by alloca. Such memory is > allocated on the stack; the code generator usually converts this to an > adjustment of the stack pointer on function entry whenever possible. >> If this is not possible, an alternate solution would be for me to >> allocate >> an array of bytes larger than all the struct types I may be using, and >> cast >> that pointer to the right type each type. In that case, I would like to >> know >> how I can find out what the size of a struct is. I've heard of people >> talking about using "the right target data", but I have no idea how to >> actually do that, and I find the doxygen info doesn't make it any >> clearer. >> > This sounds like your best option. The TargetData pass is a pass that > informs other passes of machine specific information and can, for > example, give you the number of bytes used to store a type. > > Read the document on Writing an LLVM Pass > (http://llvm.org/docs/WritingAnLLVMPass.html) to learn how to have your > pass declare the TargetData pass as a prerequisite and to get a pointer > to it when your > runOnFunction/runOnModule/runOnBasicBlock/runOn<whatever> method is > called. Then use the doxygen documentation to find the correct method > of the TargetData pass > (http://llvm.org/doxygen/classllvm_1_1TargetData.html) to use to get the > size of the type that you allocated via alloca. > > -- John T. > >> Thank you for your help, >> >> - Max >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- View this message in context: http://www.nabble.com/Explicitly-Freeing-Allocas-tp24093351p24094996.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
In the TargetData class (available from you ExecutionEngine), you have some informations available (such as StructLayout...). On Thu, Jun 18, 2009 at 5:08 PM, Nyx <mcheva at cs.mcgill.ca> wrote:> > That sounds rather cumbersome, is there no simpler way to get the actual > size > of a struct? > > > John Criswell wrote: > > > > Nyx wrote: > >> Hello, > >> > >> I would just like to ask if it's possible to explicitly free allocas. > >> This > >> is because I need to call functions that take structs of different sizes > >> as > >> input, (possibly inside of loops) and I would rather avoid a stack > >> overflow. > >> > > No, it's not legal to free memory returned by alloca. Such memory is > > allocated on the stack; the code generator usually converts this to an > > adjustment of the stack pointer on function entry whenever possible. > >> If this is not possible, an alternate solution would be for me to > >> allocate > >> an array of bytes larger than all the struct types I may be using, and > >> cast > >> that pointer to the right type each type. In that case, I would like to > >> know > >> how I can find out what the size of a struct is. I've heard of people > >> talking about using "the right target data", but I have no idea how to > >> actually do that, and I find the doxygen info doesn't make it any > >> clearer. > >> > > This sounds like your best option. The TargetData pass is a pass that > > informs other passes of machine specific information and can, for > > example, give you the number of bytes used to store a type. > > > > Read the document on Writing an LLVM Pass > > (http://llvm.org/docs/WritingAnLLVMPass.html) to learn how to have your > > pass declare the TargetData pass as a prerequisite and to get a pointer > > to it when your > > runOnFunction/runOnModule/runOnBasicBlock/runOn<whatever> method is > > called. Then use the doxygen documentation to find the correct method > > of the TargetData pass > > (http://llvm.org/doxygen/classllvm_1_1TargetData.html) to use to get the > > size of the type that you allocated via alloca. > > > > -- John T. > > > >> Thank you for your help, > >> > >> - Max > >> > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -- > View this message in context: > http://www.nabble.com/Explicitly-Freeing-Allocas-tp24093351p24094996.html > Sent from the LLVM - Dev mailing list archive at Nabble.com. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/d2cb677d/attachment.html>
I went ahead and implemented the allocation based on the maximum size of all structs seen so far... The problem is, the TargetData object from ExecutionEngine gives me a size of 12 for a struct containing a pointer and an i64 (on a 32-bit machine). However, the generated code seems to assume an alignment of 8, and tries to read the i64 value at offset 8, which obviously reads an invalid value. Does the getSizeInBytes() method from StructLayout not take the alignment into account? - Max Olivier Meurant wrote:> > In the TargetData class (available from you ExecutionEngine), you have > some > informations available (such as StructLayout...). > > > On Thu, Jun 18, 2009 at 5:08 PM, Nyx <mcheva at cs.mcgill.ca> wrote: > >> >> That sounds rather cumbersome, is there no simpler way to get the actual >> size >> of a struct? >> >> >> John Criswell wrote: >> > >> > Nyx wrote: >> >> Hello, >> >> >> >> I would just like to ask if it's possible to explicitly free allocas. >> >> This >> >> is because I need to call functions that take structs of different >> sizes >> >> as >> >> input, (possibly inside of loops) and I would rather avoid a stack >> >> overflow. >> >> >> > No, it's not legal to free memory returned by alloca. Such memory is >> > allocated on the stack; the code generator usually converts this to an >> > adjustment of the stack pointer on function entry whenever possible. >> >> If this is not possible, an alternate solution would be for me to >> >> allocate >> >> an array of bytes larger than all the struct types I may be using, and >> >> cast >> >> that pointer to the right type each type. In that case, I would like >> to >> >> know >> >> how I can find out what the size of a struct is. I've heard of people >> >> talking about using "the right target data", but I have no idea how to >> >> actually do that, and I find the doxygen info doesn't make it any >> >> clearer. >> >> >> > This sounds like your best option. The TargetData pass is a pass that >> > informs other passes of machine specific information and can, for >> > example, give you the number of bytes used to store a type. >> > >> > Read the document on Writing an LLVM Pass >> > (http://llvm.org/docs/WritingAnLLVMPass.html) to learn how to have your >> > pass declare the TargetData pass as a prerequisite and to get a pointer >> > to it when your >> > runOnFunction/runOnModule/runOnBasicBlock/runOn<whatever> method is >> > called. Then use the doxygen documentation to find the correct method >> > of the TargetData pass >> > (http://llvm.org/doxygen/classllvm_1_1TargetData.html) to use to get >> the >> > size of the type that you allocated via alloca. >> > >> > -- John T. >> > >> >> Thank you for your help, >> >> >> >> - Max >> >> >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Explicitly-Freeing-Allocas-tp24093351p24094996.html >> Sent from the LLVM - Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- View this message in context: http://www.nabble.com/Explicitly-Freeing-Allocas-tp24093351p24099580.html Sent from the LLVM - Dev mailing list archive at Nabble.com.