search for: gettypeallocsize

On Jan 20, 2013, at 3:21 , Duncan Sands <baldrick at free.fr> wrote: > if you have DataLayout available, use the getTypeAllocSize method. If you don't > have information about the target then you can use ConstantExpr::getSizeOf. The > advantage of DataLayout is that it returns a number (eg: 8) while getSizeOf > returns a mysterious expression (the optimizers will simplify it to a number, > the same as getTyp...

...t the sizeof a type? Say I've created a struct type without any explicit attribtues, and I want to call malloc() to allocate space for it. Can I get the size as an llvm::Constant* (or other llvm::Value*) given an llvm::StructType* or other llvm::Type*? if you have DataLayout available, use the getTypeAllocSize method. If you don't have information about the target then you can use ConstantExpr::getSizeOf. The advantage of DataLayout is that it returns a number (eg: 8) while getSizeOf returns a mysterious expression (the optimizers will simplify it to a number, the same as getTypeAllocSize returns,...

Is there a way to get the sizeof a type? Say I've created a struct type without any explicit attribtues, and I want to call malloc() to allocate space for it. Can I get the size as an llvm::Constant* (or other llvm::Value*) given an llvm::StructType* or other llvm::Type*? TIA, -- Rick

...45 AM, Jianzhou Zhao wrote: > >> Hello, >> >> Can I define a named type ?   %rt = {%rt} >> llvm-as can parse this definition without errors. >> >> JIT executes '%0 = alloca %rt' as allocating a memory with size 0. >> Because the llvm::TargetData::getTypeAllocSize accually returns 0 in >> this case. The function that calculates %rt's size is by the >> TargetData::getStructLayout, which calculates the a layout of %rt. It >> can only returns 0 when the element type %rt is not defined yet, since >> the result is infinite otherwise. &...

Hello, Can I define a named type ? %rt = {%rt} llvm-as can parse this definition without errors. JIT executes '%0 = alloca %rt' as allocating a memory with size 0. Because the llvm::TargetData::getTypeAllocSize accually returns 0 in this case. The function that calculates %rt's size is by the TargetData::getStructLayout, which calculates the a layout of %rt. It can only returns 0 when the element type %rt is not defined yet, since the result is infinite otherwise. Is %rt = {%rt} still a valid or usef...

...est way to do what I'm trying to do, but it's not useless and bogus. Consider the following: %1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type i32* and ; the size of that is sizeof(void *) bytes Having said that I am looking at the target data getTypeAllocSize method. Daniel 2009/10/20 Duncan Sands <baldrick at free.fr> > Óscar Fuentes wrote: > >> Daniel Waterworth <da.waterworth at googlemail.com> writes: >> >> [snip] >> >> Use the getElementType method of PointerType. >> >> size_t size; &g...

...er::expandAddToGEP(llvm::SCEV const* const*, llvm::SCEV const* const*, llvm::PointerType const*, llvm::Type const*, llvm::Value*)in libLLVMAnalysis.a(ScalarEvolutionExpander.cpp.o) "llvm::TargetData::getABITypeAlignment(llvm::Type const*) const", referenced from: llvm::TargetData::getTypeAllocSize(llvm::Type const*) constin libLLVMAsmPrinter.a(AsmPrinter.cpp.o) llvm::TargetData::getTypeAllocSize(llvm::Type const*) constin libLLVMSelectionDAG.a(TargetLowering.cpp.o) llvm::SelectionDAG::getEVTAlignment(llvm::EVT) constin libLLVMSelectionDAG.a(SelectionDAG.cpp.o) getMemsetStor...

Daniel Waterworth <da.waterworth at googlemail.com> writes: [snip] Use the getElementType method of PointerType. >> size_t size; >> if (isa<PointerType>(allocated_type)) { >> size = sizeof(void*) * 8; >> } else { >> size = allocated_type->getPrimitiveSizeInBits(); >> } >> // size now equals the size (in bits) of the type allocated

...gt;(allocated_type)) { >>> size = sizeof(void*) * 8; >>> } else { >>> size = allocated_type->getPrimitiveSizeInBits(); >>> } >>> // size now equals the size (in bits) of the type allocated > > This looks suspicious to me. Probably he wants getTypeAllocSize (available from target data). The special casing of PointerType is both useless and bogus. Ciao, Duncan.

On Nov 11, 2010, at 8:45 AM, Jianzhou Zhao wrote: > Hello, > > Can I define a named type ? %rt = {%rt} > llvm-as can parse this definition without errors. > > JIT executes '%0 = alloca %rt' as allocating a memory with size 0. > Because the llvm::TargetData::getTypeAllocSize accually returns 0 in > this case. The function that calculates %rt's size is by the > TargetData::getStructLayout, which calculates the a layout of %rt. It > can only returns 0 when the element type %rt is not defined yet, since > the result is infinite otherwise. > > Is %rt...

I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` is returning `12`. `getStructLayout` also gives an `4` offset for the second element. The native ABI, and clang, for the same type are producing a size of 16, with an alignment of 8, for the second element. This is for the system triple "x86_64-linux-gnu" What could be causing this di...

How are bitfields handled in StructLayout? In LLVM 2.5 the struct is unambiguously size by: StructSize += TD.getTypePaddedSize(Ty); // Consume space for this data In LLVM 2.6 it's getTypeAllocSize, which does the same thing. Unfortunately, this is not correct for bitfields. For example, LLVM reports this struct: typedef struct test1 { short f0 : 10; char f1 : 5; long f2 : 1; long f3 : 45; } test1_t; which in LLVM is: %test1 = type { i10, i5, i1, i45 } to have size 12 on x86-64...

Dear LLVM contributors, I work on the "Improvement of vectorization process in Polly". At the moment I'm trying to implement tiling, interchanging and unrolling of specific loops based on the following algorithm for the analytical modeling [1]. It requires information about the following parameters of a target architecture: 1. Size of double-precision floating-point number. 2.

It sounds like your DataLayout may not match clang's for x86_64-linux. What does it say about the alignment of i64? On Wed, Apr 18, 2018 at 12:05 PM edA-qa mort-ora-y via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` > is returning `12`. `getStructLayout` also gives an `4` offset for the > second element. > The native ABI, and clang, for the same type are producing a size of 16, > with an alignment of 8, for the second element. > This is for the system triple "x86_64-linux-gnu" >...

I'm implementing c style "sizeof()", and I did as http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt illuarstrated, and it works find, here's an example of my implementation: auto *p = builder.CreateGEP(structTy, llvm::ConstantPointerNull::get(pointerTy), constint1); auto *size =

...= LI ? LI->getPointerOperand() : SI->getPointerOperand(); unsigned Alignment = LI ? LI->getAlignment() : SI->getAlignment(); + if (Alignment == 0) + Alignment = 1; unsigned AddressSpace = Ptr->getType()->getPointerAddressSpace(); unsigned ScalarAllocatedSize = DL->getTypeAllocSize(ScalarDataTy); unsigned VectorElementSize = DL->getTypeStoreSize(DataTy)/VF; Should fix this. On Nov 15, 2013, at 3:49 PM, Joshua Klontz <josh.klontz at gmail.com> wrote: > Nadav, > > I believe aligned accesses to unaligned pointers is precisely the issue. Consider the func...

...est way to do what I'm trying to do, but it's not > useless and bogus. Consider the following: > > %1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type > i32* and > ; the size of that is sizeof(void *) bytes it is useless because getTypeAllocSize will handle any type, including pointer types. It is bogus because your code assumes that the LLVM bitcode is targeting your own machine, i.e. that sizeof(void*) as given by your machine is correct for the target. This may or may not be the case, but it is something best avoided. Ciao, Duncan.

...n't think it is really right. An alignment of 0 is supposed to mean the platform default alignment (IIRC, DataLayout::getPrefTypeAlignment tells you what it is). -Hal > unsigned AddressSpace = Ptr->getType()->getPointerAddressSpace(); > unsigned ScalarAllocatedSize = DL->getTypeAllocSize(ScalarDataTy); > unsigned VectorElementSize = DL->getTypeStoreSize(DataTy)/VF; > > Should fix this. > > On Nov 15, 2013, at 3:49 PM, Joshua Klontz <josh.klontz at gmail.com> > wrote: > > > Nadav, > > > > I believe aligned accesses to unaligned...

...e your DataLayout may not match clang's for x86_64-linux. What > does it say about the alignment of i64? > On Wed, Apr 18, 2018 at 12:05 PM edA-qa mort-ora-y via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` >> is returning `12`. `getStructLayout` also gives an `4` offset for the >> second element. >> The native ABI, and clang, for the same type are producing a size of 16, >> with an alignment of 8, for the second element. >> This is for the system triple "x86_64-lin...

...really right. An alignment of 0 is supposed to mean the platform default alignment (IIRC, DataLayout::getPrefTypeAlignment tells you what it is). > > -Hal > >> unsigned AddressSpace = Ptr->getType()->getPointerAddressSpace(); >> unsigned ScalarAllocatedSize = DL->getTypeAllocSize(ScalarDataTy); >> unsigned VectorElementSize = DL->getTypeStoreSize(DataTy)/VF; >> >> Should fix this. >> >> On Nov 15, 2013, at 3:49 PM, Joshua Klontz <josh.klontz at gmail.com> >> wrote: >> >>> Nadav, >>> >>> I be...