search for: gettypesizeinbit

...> > Another example is 80-bit floating point types. Here (1), (2) > > and (3) are presumably 80 bits. On my machine (5) is 96 bits. > > I'm not sure what (4) is, presumably 80 or 96. > > > > Which (if any) of these should getTypeSize, getABITypeSize, > > getTypeSizeInBits > > and getABITypeSizeInBits correspond to? > > TypeSize == "real size", ABITypeSize == "abi size". You will need > another pair for the storage size? What is "real size"? Do you mean getTypeSizeInBits rounded up to a multiple of 8? That was my fi...

...other example is 80-bit floating point types. Here (1), (2) >>> and (3) are presumably 80 bits. On my machine (5) is 96 bits. >>> I'm not sure what (4) is, presumably 80 or 96. >>> >>> Which (if any) of these should getTypeSize, getABITypeSize, >>> getTypeSizeInBits >>> and getABITypeSizeInBits correspond to? >> >> TypeSize == "real size", ABITypeSize == "abi size". You will need >> another pair for the storage size? > > What is "real size"? Do you mean getTypeSizeInBits rounded up to a > mult...

...ger object (i.e. 40?). > > Another example is 80-bit floating point types. Here (1), (2) > and (3) are presumably 80 bits. On my machine (5) is 96 bits. > I'm not sure what (4) is, presumably 80 or 96. > > Which (if any) of these should getTypeSize, getABITypeSize, > getTypeSizeInBits > and getABITypeSizeInBits correspond to? TypeSize == "real size", ABITypeSize == "abi size". You will need another pair for the storage size? > > It seems clear that getTypeSizeInBits corresponds to (1) and (2), as > shown by it returning 36 for i36. This is l...

...east as big as (3). (5) needs to be at least as big as (4). Another example is 80-bit floating point types. Here (1), (2) and (3) are presumably 80 bits. On my machine (5) is 96 bits. I'm not sure what (4) is, presumably 80 or 96. Which (if any) of these should getTypeSize, getABITypeSize, getTypeSizeInBits and getABITypeSizeInBits correspond to? It seems clear that getTypeSizeInBits corresponds to (1) and (2), as shown by it returning 36 for i36. This is like gcc's TYPE_PRECISION, and is a useful concept - but I think the name should be changed, since right now it implicitly suggests it return...

...st for the XCore backend. I tracked this down to the following code in TargetData.cpp: if (GV->hasInitializer() && GVAlignment == 0) { if (Alignment < 16) { // If the global is not external, see if it is large. If so, give it a // larger alignment. if (getTypeSizeInBits(ElemType) > 128) Alignment = 16; // 16-byte alignment. } } I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive...

...OS X. I am getting the following error. I have modified lli to load qt libraries. When I use with option mcjit, I get the following error lli -use-mcjit -debug-ir bitcodetestqtapp Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file /Users/shailesh/repos/llvm/include/llvm/IR/DataLayout.h, line 449. 0  lli               0x0000000102244f3e llvm::sys::PrintStackTrace(__sFILE*) + 46 1  lli               0x000000010224524b PrintStackTraceSignalHandler(void*) + 27 2  lli               0x0000000102245559 SignalHandler(int) + 2...

...t() > Alignment) Alignment = GV->getAlignment(); ==================== confusion starts ======================== if (GV->hasInitializer()) { if (Alignment < 16) { // If the global is not external, see if it is large. If so, give it a // larger alignment. if (getTypeSizeInBits(ElemType) > 128) Alignment = 16; // 16-byte alignment. } } ==================== confusion ends ========================= return Alignment; }

...OS X. I am getting the following error. I have modified lli to load qt libraries. When I use with option mcjit, I get the following error lli -use-mcjit -debug-ir bitcodetestqtapp Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file /Users/shailesh/repos/llvm/include/llvm/IR/DataLayout.h, line 449. 0 lli 0x0000000102244f3e llvm::sys::PrintStackTrace(__sFILE*) + 46 1 lli 0x000000010224524b PrintStackTraceSignalHandler(void*) + 27 2 lli 0x0000000102245559 SignalHandler(int) + 2...

...09. I made an NFC refactoring in > InstSimplify at r275911 that isn't in the branch, so I don't think the patch > will apply as-is. For safety, you could apply the one-line fix without > pulling the refactoring into the branch with this diff: > > - unsigned BitWidth = Q.DL.getTypeSizeInBits(TrueVal->getType()); > + unsigned BitWidth = > + Q.DL.getTypeSizeInBits(TrueVal->getType()->getScalarType()); > > > > > On Fri, Jul 22, 2016 at 7:45 AM, Hans Wennborg <hans at chromium.org> wrote: >> >> Sanjay: let me know if this is someth...

...) You can get a Function pointer in LowerFormalArguments, and in LowerCall only when Callee can by dyn_casted to a GlobalAddressSDNode. By having this pointer you can then do: for (Function::const_arg_iterator I = F->arg_begin(), E = F->arg_end();I != E; ++I) { unsigned Bytes = TD->getTypeSizeInBits(I->getType()) / 8; // do stuff here } 2) The second case is when the dyn_cast above fails because the Callee SDValue is a ExternalSymbolSDNode. In this case you have to manually analyze the arguments using PartOffset. -------------- next part -------------- An HTML attachment was scrub...

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

...factoring in >> InstSimplify at r275911 that isn't in the branch, so I don't think the patch >> will apply as-is. For safety, you could apply the one-line fix without >> pulling the refactoring into the branch with this diff: >> >> - unsigned BitWidth = Q.DL.getTypeSizeInBits(TrueVal->getType()); >> + unsigned BitWidth = >> + Q.DL.getTypeSizeInBits(TrueVal->getType()->getScalarType()); >> >> >> >> >> On Fri, Jul 22, 2016 at 7:45 AM, Hans Wennborg <hans at chromium.org> wrote: >>> >>> S...

...ackend. I tracked this down to the following code in TargetData.cpp: > > if (GV->hasInitializer() && GVAlignment == 0) { > if (Alignment < 16) { > // If the global is not external, see if it is large. If so, give it a > // larger alignment. > if (getTypeSizeInBits(ElemType) > 128) > Alignment = 16; // 16-byte alignment. > } > } > > I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make...

...tSimplify at r275911 that isn't in the branch, so I don't think the > patch > >> will apply as-is. For safety, you could apply the one-line fix without > >> pulling the refactoring into the branch with this diff: > >> > >> - unsigned BitWidth = Q.DL.getTypeSizeInBits(TrueVal->getType()); > >> + unsigned BitWidth = > >> + Q.DL.getTypeSizeInBits(TrueVal->getType()->getScalarType()); > >> > >> > >> > >> > >> On Fri, Jul 22, 2016 at 7:45 AM, Hans Wennborg <hans at chromium.org &gt...

...>getAlignment(); > > ==================== confusion starts ======================== > if (GV->hasInitializer()) { > if (Alignment< 16) { > // If the global is not external, see if it is large. If so, give it a > // larger alignment. > if (getTypeSizeInBits(ElemType)> 128) > Alignment = 16; // 16-byte alignment. > } > } > ==================== confusion ends ========================= > > return Alignment; > } > _______________________________________________ > LLVM Developers mailing list > LLVM...

Hello, I would like to keep info about size and type info of all instructions ( and Values at the same time). I can do this by extracting type of the Values, but if I have still some unused instructions , I can't keep track on them. I try to convert them to Value and get the type or simply get the type of instruction, but have the following error: Assertion `Ty->isSized() &&

Sanjay: let me know if this is something that will apply to 3.9. Thanks, Hans On Wed, Jul 20, 2016 at 5:59 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Quick update - the bug existed before I refactored that chunk in > InstSimplify with: > https://reviews.llvm.org/rL275911 > > In fact, as discussed in https://reviews.llvm.org/D22537 - because we have a

...t; really reliable. FWIW, it looks like almost all (if not all) of the vectorize compile failures are due to other passes not handling pointer vectors appropriately. For example, lib/Analysis/ValueTracking.cpp contains this code: 427 if (SrcTy->isPointerTy()) 428 SrcBitWidth = TD->getTypeSizeInBits(SrcTy); 429 else 430 SrcBitWidth = SrcTy->getScalarSizeInBits(); and this does not work for pointer vectors. In this case, the solution (for the crash, which happens because getScalarSizeInBits returns 0 for pointer vectors) seems obvious, although fixing it to not crash and making s...

...FileImpl.cpp.o) llvm::TargetLoweringObjectFileCOFF::~TargetLoweringObjectFileCOFF()in libLLVMCodeGen.a(TargetLoweringObjectFileImpl.cpp.o) llvm::TargetLoweringObjectFileCOFF::~TargetLoweringObjectFileCOFF()in libLLVMCodeGen.a(TargetLoweringObjectFileImpl.cpp.o) "llvm::TargetData::getTypeSizeInBits(llvm::Type const*) const", referenced from: llvm::TargetData::getTypeStoreSize(llvm::Type const*) constin libLLVMAsmPrinter.a(AsmPrinter.cpp.o) llvm::TargetData::getTypeStoreSize(llvm::Type const*) constin libLLVMSelectionDAG.a(TargetLowering.cpp.o) llvm::TargetData::getType...

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Jingyue Wu" <jingyue at google.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, June 30, 2015 8:16:13 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > > Hi Adam, > > Jingyue is right. We need to keep