search for: gettypesize

On Oct 7, 2007, at 11:23 AM, Duncan Sands wrote: > Now that I'm working on codegen support for arbitrary precision > integers (think i36 or i129), I've hit the problem of what > getTypeSize and friends should return for such integers (the > current implementations seem to me to be wrong). However it's > not clear to me how getTypeSize and friends are defined. > > There seem to be several possible meanings for the size of a type > (only talking about primitive types...

Now that I'm working on codegen support for arbitrary precision integers (think i36 or i129), I've hit the problem of what getTypeSize and friends should return for such integers (the current implementations seem to me to be wrong). However it's not clear to me how getTypeSize and friends are defined. There seem to be several possible meanings for the size of a type (only talking about primitive types here): (1) The minimum...

Hi Evan, thanks for replying. > > Now that I'm working on codegen support for arbitrary precision > > integers (think i36 or i129), I've hit the problem of what > > getTypeSize and friends should return for such integers (the > > current implementations seem to me to be wrong). However it's > > not clear to me how getTypeSize and friends are defined. > > > > There seem to be several possible meanings for the size of a type > > (only talk...

On Oct 8, 2007, at 12:47 PM, Duncan Sands wrote: > Hi Evan, thanks for replying. > >>> Now that I'm working on codegen support for arbitrary precision >>> integers (think i36 or i129), I've hit the problem of what >>> getTypeSize and friends should return for such integers (the >>> current implementations seem to me to be wrong). However it's >>> not clear to me how getTypeSize and friends are defined. >>> >>> There seem to be several possible meanings for the size of a type >>...

I do not have a strong opinion on the naming of the various size functions, or on how to deal with APInt's of sizes that are not multiples of a byte. I do think loading and storing more bytes than necessary is generally a bad idea, especially if you're getting uninitialized bits. (If you incorrectly cross a page boundary, you might fault, for one thing. Watch out for packed

Hi Evan, > I think rather than worrying about how these functions are being used > *now* you should define them in a way that's clear and fix the > incorrect uses. To me that means: > > getTypeSizeInBits - actual size > getABITypeSizeInBits - ABI size when used in a larger structure > getStorageTypeSizeInBits - size of load / store I agree and will try to do something later this week. Ciao, Duncan. PS: getStorageTypeSizeInBits -> getTypeStorageSizeInBits

...har' is always troublesome, though in C++ it is a discrete type. I made the following change in my copy (clang-3.3) that I think is a correct and valid change: File: tools/clang/lib/Sema/SemaChecking.cpp Function: Sema::GetSignedVectorType() Replace the fragment: if (TypeSize == Context.getTypeSize(Context.CharTy)) return Context.getExtVectorType(Context.CharTy, VTy->getNumElements()); ^^^^^^ with: if (TypeSize == Context.getTypeSize(Context.CharTy)) return Context.getExtVectorType(Context.SignedCharTy, VTy->getNumElements());...

...==== --- gcc/llvm-convert.cpp (revision 166) +++ gcc/llvm-convert.cpp (working copy) @@ -2202,18 +2202,23 @@ // Figure out how large the element pointed to is. const Type *ElTy = cast<PointerType>(LHS->getType())- >getElementType(); - int64_t EltSize = TD.getTypeSize(ElTy); + + if (!ElTy->isAbstract()) { + // We can only get the type size (and thus convert to using a GEP instr) + // if the type isn't abstract + int64_t EltSize = TD.getTypeSize(ElTy); - // If EltSize exactly divides Offset, then we know that we can turn this -...

...it is a discrete type. I made > the following change in my copy (clang-3.3) that I think is a correct and > valid change: > > File: tools/clang/lib/Sema/SemaChecking.cpp > Function: Sema::GetSignedVectorType() > > Replace the fragment: > > if (TypeSize == Context.getTypeSize(Context.CharTy)) > return Context.getExtVectorType(Context.CharTy, > VTy->getNumElements()); > ^^^^^^ > with: > if (TypeSize == Context.getTypeSize(Context.CharTy)) > return Context.getExtVectorType(Context.SignedCharTy, > VT...

...har' is always troublesome, though in C++ it is a discrete type. I made the following change in my copy (clang-3.3) that I think is a correct and valid change: File: tools/clang/lib/Sema/SemaChecking.cpp Function: Sema::GetSignedVectorType() Replace the fragment: if (TypeSize == Context.getTypeSize(Context.CharTy)) return Context.getExtVectorType(Context.CharTy, VTy->getNumElements()); ^^^^^^ with: if (TypeSize == Context.getTypeSize(Context.CharTy)) return Context.getExtVectorType(Context.SignedCharTy, VTy->getNumElements());...

...x37)[0x84bcbab] lli(_ZN4llvm16ExecutionContextD1Ev+0x14)[0x84bd780] lli(_ZN9__gnu_cxx13new_allocatorIN4llvm16ExecutionContextEE7destroyEPS2_+0x11)[0x84bd7af] ... ... I checked the llvm svn log, this is due to the patch from " svn diff -r43619:43620" The replacement of getABITypeSize with getTypeSize caused it. This seems an alignment unmatch issue. As for type i75, the getABITypeSize/getABITypeAlignment will return 10 while in APInt, it actually allocated two-64bit-array (128bit totally) hence the malloc/free crashed. Ciao, can you take a look at it? -------------- next part -------------- A...

To figure out the size of data varaibles for my backend, I tries this code stolen from X86 backend: const TargetData& TD = m_tm.getTargetData(); unsigned size = TD.getTypeSize(initializer->getType()); However, the getTypeInfo function in TargetData.cpp contains this: case Type::VoidTyID: case Type::BoolTyID: case Type::UByteTyID: case Type::SByteTyID: Size = 1; Alignment = TD->getByteAlignment(); return; The problem is that my target can...