search for: integertyid

The LLVM docs seem to indicate that integer types are considered primitive, however looking at the code I see `FirstDerivedTyID = IntegerTyID`, implying that integers are derived rather than primitive. Should the docs be updated? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130811/4b8e5e02/attachment.html>

...nst PointerType *PTy = dyn_cast<PointerType>(...)) { const Type *InnerTy = PTy->getElementType(); switch (InnerTy->getTypeID()) { case Type::ArrayTyID: ... case Type::FunctionTyID: ... case Type::StructTyID: ... case Type::IntegerTyID: ... } } A switch on getTypeID() is equivalent to isa<>, but more efficient than a chain of if's when doing multiple tests. If you only care about whether it's first class or not, you can just call InnerTy->isFirstClass(). Nick Lewycky

Hello, I am writing an optimization pass which optimizes code based on an online pointer analysis algorithm and need to detect pointers which are pointing to derived types. I have not had any problem identifying pointers in general using isa<PointerType>(...), but I can't seem to figure out how I can make sure that the pointer is pointing to a scalar value and not a function, array,

...const UnionType *UnTy = cast<UnionType>(Ty); + uint64_t Size = 0; + for (UnionType::element_iterator i = UnTy->element_begin(), + e = UnTy->element_end(); i != e; ++i) { + Size = std::max(Size, getTypeSizeInBits(*i)); + } + return Size; + } case Type::IntegerTyID: return cast<IntegerType>(Ty)->getBitWidth(); case Type::VoidTyID: @@ -516,6 +525,17 @@ unsigned Align = getAlignmentInfo(AGGREGATE_ALIGN, 0, abi_or_pref, Ty); return std::max(Align, (unsigned)Layout->getAlignment()); } + case Type::UnionTyID: { + const UnionTyp...

Hello, I noticed a bit of a gap in the current code for unions: a ConstantUnion cannot be written out to .ll. Hopefully I'm not stepping on Talin's toes by posting this, it's a fairly straightforward adaptation of the code for structs just above. Tim. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --------------

...e>(...)) { > const Type *InnerTy = PTy->getElementType(); > switch (InnerTy->getTypeID()) { > case Type::ArrayTyID: > ... > case Type::FunctionTyID: > ... > case Type::StructTyID: > ... > case Type::IntegerTyID: > ... > } > } > > -- View this message in context: http://www.nabble.com/Using-isa-with-derived-types-tp20472959p20903806.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

...ome think like 0x1253.. ) also I tried to get the type of the instruction with switch (II->getType()->getTypeID()) { case Type::FloatTyID: case Type::DoubleTyID: case Type::IntegerTyID: default: ; } It works well exept for the getelementptr instruction !!! ?? so Please how to get the Operand type ? (I mean that tell me it is a Double or a float .... ) Thank you so...

...y points out. CC-ing Chris as this is really his call. -Chandler On Sun, Aug 11, 2013 at 4:52 PM, Keno Fischer <kfischer at csail.mit.edu>wrote: > The LLVM docs seem to indicate that integer types are considered > primitive, however looking at the code I see `FirstDerivedTyID = > IntegerTyID`, implying that integers are derived rather than primitive. > Should the docs be updated? > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev...

Hi all, We're hitting some walls here when generating the correct structure layout for specific C++ ABI requirements, and I was wondering how much StructLayout could help. For instance, the ABI has some complicated rules on the size of derived classes (http://www.codesourcery.com/public/cxx-abi/abi.html#class-types) and LLVM struct type cannot reflect that in full. Example: // CHECK:

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached