search for: compositetyp

...ElementCount EC); Type *getElementType() const; ElementCount getElementCount() const; bool isScalable() const; }; class FixedVectorType : public VectorType, public SequentialType { public: static FixedVectorType *get(Type *ElementType, unsigned NumElts); }; class SequentialType : public CompositeType { public: uint64_t getNumElements() const { return NumElements; } }; In this proposed architecture, VectorType does not have a getNumElements() function because it does not inherit from SequentialType. In generic code, users will call VectorType::get() to obtain a new instance of...

...ElementCount EC); Type *getElementType() const; ElementCount getElementCount() const; bool isScalable() const; }; class FixedVectorType : public VectorType, public SequentialType { public: static FixedVectorType *get(Type *ElementType, unsigned NumElts); }; class SequentialType : public CompositeType { public: uint64_t getNumElements() const { return NumElements; } }; In this proposed architecture, VectorType does not have a getNumElements() function because it does not inherit from SequentialType. In generic code, users will call VectorType::get() to obtain a new instance of...

...st; > > bool isScalable() const; > > }; > > > > class FixedVectorType : public VectorType, public SequentialType { > > public: > > static FixedVectorType *get(Type *ElementType, unsigned NumElts); > > }; > > > > class SequentialType : public CompositeType { > > public: > > uint64_t getNumElements() const { return NumElements; } > > }; > > In this proposed architecture, VectorType does not have a getNumElements() function because it does not inherit from SequentialType. In generic code, users will call Vecto...

...entType, ElementCount EC); Type *getElementType() const; ElementCount getElementCount() const; bool isScalable() const; }; class FixedVectorType : public VectorType, public SequentialType { public: static FixedVectorType *get(Type *ElementType, unsigned NumElts); }; class SequentialType : public CompositeType { public: uint64_t getNumElements() const { return NumElements; } }; In this proposed architecture, VectorType does not have a getNumElements() function because it does not inherit from SequentialType. In generic code, users will call VectorType::get() to obtain a new instance of VectorType just a...

...needed (anymore)? Anyway, when one removes this cast and also makes the other getIndexedType implementation (which is called by this one) a template, passing in an iterator over unsigned should also work. The actual types over which an iterator is allowed should now be limited by the parameters to CompositeType::indexValid() and CompositeType::getTypeAtIndex() (which currently are Value* or unsigned). I've attached a patch which does exactly this. Since my template-fu is not so strong, please review :-) I've also attached another patch to argpromotion, which passes an unsigned iterator to getInd...

...terType>(Ptr); - if (!PTy) return 0; // Type isn't a pointer type! - const Type *Agg = PTy->getElementType(); - - // Handle the special case of the empty set index set... - if (NumIdx == 0) - return Agg; - - unsigned CurIdx = 1; - for (; CurIdx != NumIdx; ++CurIdx) { - const CompositeType *CT = dyn_cast<CompositeType>(Agg); - if (!CT || isa<PointerType>(CT)) return 0; - Value *Index = Idxs[CurIdx]; - if (!CT->indexValid(Index)) return 0; - Agg = CT->getTypeAtIndex(Index); - - // If the new type forwards to another type, then it is in the middle -...

...(Instruction*)CI, call_print1); //insert the call instruction But getting the error on the ConstantExpr::getGetElementPtr() function. opt: /home/arnie/llvm-clang/llvm/include/llvm/Support/Casting.h:194: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X = llvm::CompositeType, Y = llvm::Type*, typename llvm::cast_retty<To, From>::ret_type = llvm::CompositeType*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed. What might I be doing wrong? Thanks a lot; -- Arnamoy Bhattacharyya Athabasca Hall 143...

...dxs, + unsigned NumIdx) { const PointerType *PTy = dyn_cast<PointerType>(Ptr); if (!PTy) return 0; // Type isn't a pointer type! const Type *Agg = PTy->getElementType(); @@ -1089,7 +1093,7 @@ for (; CurIdx != NumIdx; ++CurIdx) { const CompositeType *CT = dyn_cast<CompositeType>(Agg); if (!CT || isa<PointerType>(CT)) return 0; - Value *Index = Idxs[CurIdx]; + IndexTy Index = Idxs[CurIdx]; if (!CT->indexValid(Index)) return 0; Agg = CT->getTypeAtIndex(Index); @@ -1103,6 +1107,18 @@ return CurIdx == N...

On Jul 22, 2008, at 11:54 PM, Matthijs Kooijman wrote: > Hi Chris, > > >> I'd prefer to not turn this into a template. Why not just define a >> version that takes an array of uint64_t's or something like that? > because I want to be able to pass in iterators. I could define a > version that > takes std<uint64_t>::iterators, but next thing we know, we

...ding the appropriate case. :) Hi Talin, thanks for looking in to this. I think there's already a lot of code that makes the assumption that the different members of a StructType represent distinct storage. Why is it easier to co-opt StructType than to create a new 'UnionType' under CompositeType? What's the tradeoff? Nick

...mprovement now. If you look at CGDebugInfo.cpp in clang, you'll see "Unit" variable/argument used all over the place. IMO, majority of these could be eliminated thanks to DIBuilder. Another significant improvement is that it does not expose internal data structures (e.g. DerivedType, CompositeType... ) to FEs. The front-end should not be forced to learn about them and they do not directly represent any DWARF concept anyway. It is just an approach used my predecessor to communicate debug info from FE to llvm code generator. Now, with the encapsulation provided by DIBuilder, we have more fr...

Hello I have a pointer to llvm::Value *,I know its a pointer to some llvm::CompositeType (vector) Could you please tell me how can I get a value of specific index in the vector. Thank you. Yakov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111107/0b475afd/attachment.html>

...ed, it returns the value of the instance variable NumElementspresent in VectorType objects, but we passed in a PointerType (SequentialType), which doesn't havethis variable but have at the same position one variable representing the type of the pointed thing. 00309 class SequentialType : public CompositeType {00310 Type *ContainedType; So getNumElements() will return some part of the value of ContainedType (an address), whichexplains that big integer vectors. Do you think this is an expected behaviour or a bug? Regards,Gabriel -------------- next part -------------- An HTML attachment...

...gt; I was a little uncertain as to how to write the tests. I'd particularly like to write tests for the bitcode reader/writer stuff, but I am not sure how to do that. A reasonable example are tests like test/Feature/newcasts.ll Here are some thoughts on your patch: +class UnionType : public CompositeType { ... + /// UnionType::get - Create an empty union type. + /// + static UnionType *get(LLVMContext &Context) { + return get(Context, std::vector<const Type*>()); + } I don't think that an empty union is going to be important enough to add a special accessor for it. Is an emp...

On 24 February 2011 21:34, Jason Kim <jasonwkim at google.com> wrote: > On Thu, Feb 24, 2011 at 1:29 PM, Devang Patel <dpatel at apple.com> wrote: It simplified a bit type construction but the overall code did not reduce that much. It's still very similar to the previous style but had a few differences in the IR output. We had LIT tests that checked the IR and Dwarf and GDB

This patch adds a UnionType to DerivedTypes.h. It also adds code to the bitcode reader / writer and the assembly parser for the new type, as well as a tiny .ll test file in test/Assembler. It does not contain any code related to code generation or type layout - I wanted to see if this much was acceptable before I proceeded any further. Unlike my previous patch, in which the Union type was

Chris Lattner wrote: > On Dec 30, 2008, at 12:41 PM, Talin wrote: > >> I've been thinking about how to represent unions or "disjoint types" >> in LLVM IR. At the moment, the only way I know to achieve this right >> now is to create a struct that is as large as the largest type in >> the union and then bitcast it to access the fields contained

...d? So far I am still quite the novice with LLVM internals but looking over the code it looks like one could hack in most of the required functionality up to the DAG building stage. I am not sure if this would work so perhaps I could get some opinions. My thoughts were as follows- introduce a new CompositeType called union (possibly refactoring some stuff into a common parent class from StructType). Recycle GEP (using RTTI) to handle UnionType field lookups as well. Add type codes into bitreader/bitwriter which would cope with the new union type. Add u { ... } into the AsmParser. Revise some of the t...

...onstant integer should do just fine, so I would propose to drop the bitwidth check such that any ConstantInt is valid. This change should also be made to SequentialType, which can be indexed by any integer type as well. I've attached a patch, which makes any integer type valid for indexing an CompositeType. The side effect is now that GEP no longer poses any conditions on it's indices (since it delegated that to indexValid, which is not the right place IMHO). I guess those checks need to explicitely added somewhere in GetElementPtrInst. Gr. Matthijs -------------- next part -------------- A no...

...LLVM internals > but looking over the code it looks like one could hack in > most of the required functionality up to the DAG building > stage. I am not sure if this would work so perhaps I could > get some opinions. > > > > My thoughts were as follows- introduce a new > CompositeType called union (possibly refactoring some stuff > into a common parent class from StructType). > > > > Recycle GEP (using RTTI) to handle UnionType field > lookups as well. Add type codes into bitreader/bitwriter > which would cope with the new union type. Add u { ... } into &gt...