search for: getsizeinbyt

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

...d generalize anything that works in terms of bytes to work in terms of address units. I think you'll need to extend the datalayout string syntax to support an address unit size (in bits), and to add an address unit size field to the TargetData class. You'll also need to change APIs like getSizeInBytes to getSizeInAddressUnits. Then, you can change your target datalayout string to be in terms of 16-bit address units instead of 8-bit address units. Then there are other places in LLVM which hardcode "8" constants and "i8*" types; these can be fixed once the TargetData change...

> > At first I thought this could be handled when lowering > loads and stores, but I realize that I can only catch the > targeted addresses of loads/stores here - however address > calculation nodes may occur anywhere in a DAG. > > > > So my first impulse would be to adjust the constants when > the GEP instructions are transformed to ADDs. Afaics his > would mean

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

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

I agree that consensus seems to be missing. There's definitely some assumptions, and more in particular, API and usage assumptions around 8 bit bytes in the backends. Also: How do you plan on keeping these assumptions from creeping back in? -eric On Thu, May 9, 2019 at 10:30 AM JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On May 9, 2019, at 5:29 AM,