search for: functiontyid

...sing? Please see the doxygen: http://llvm.org/doxygen/classllvm_1_1Type.html if (const 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...

...these two lines redundant? The isFirstClassType() only disallows function types, void, and opaque: 236 inline bool isFirstClassType() const { 237 // There are more first-class kinds than non-first-class kinds, so a 238 // negative test is simpler than a positive one. 239 return ID != FunctionTyID && ID != VoidTyID && ID != OpaqueTyID; 240 } Is struct typ also a first class type? -- Jianzhou

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,

...://llvm.org/doxygen/classllvm_1_1Type.html > > if (const 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: > ... > } > } > > -- View this message in context: http://www.nabble.com/Using-isa-with-derived-types-tp20472959p20903806.html Sent from the LLVM - Dev mai...

Dear Reid and Chris, I thought I should send this to the list in case anyone else is struggling to interpret bytecode files with the new docs. (1) First a bug I already mentioned to Reid. Unlike the other new module headers module 0x01 still uses the old 32-bit and 32-bit format instead of the new 5-bit and 27-bit format. Thus the first module in the file will be 0x00000001 followed by

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:

...nto the IR using a llvm frontend. I have written a module-pass which will take in the IR thus generated and iterate over the various types (classes/structs) defined in the source. For every such type, I will iterate over the sub-types (types of its members). I was expecting to see a member of type *FunctionTyID* to indicate a member function but this is not the case. Hence, I am not able to iterate over the member functions. On looking into the IR (dumped out in human readable format), I see that the class defined in the source code has been stripped out of its member functions and only a structure conta...

...the "Type != Value" change that happened in >1.3. In 1.2, we had (in Type.h): Yes. This was one of those items that was buried back in the upgrade section. Lazy skimmers like myself will get confused and ask about this. >DoubleTyID = 11 >TypeTyID = 12 >LabelTyID = 13 >FunctionTyID = 14 > >We now have: >DoubleTyID = 11 >LabelTyID = 12 >FunctionTyID = 13 > >So, we eliminated TypeTyID (one of the main points of the change was to >get rid of this) and shifted down the values higher than it was before. >So, the new value for a label is 12 and, as you no...

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