search for: sequentialtype

Hi, I am helping with the effort to implement scalable vectors in the codebase in order to add support for generating SVE code in the Arm backend. I would like to propose a refactor of the Type class hierarchy in order to eliminate issues related to the misuse of SequentialType::getNumElements(). I would like to introduce a new class FixedVectorType that inherits from SequentialType and VectorType. VectorType would no longer inherit from SequentialType, instead directly inheriting from Type. After this change, it will be statically impossible to accidentally call Sequenti...

Hi all, An oddity that has existed for a long time in the IR is that PointerType derives from SequentialType. Per subject I propose to make PointerType derive from Type for a couple of reasons: - Values of type PointerType are unlike the other SequentialTypes (arrays and vectors) in that they do not hold values of the element type. By moving PointerType we can unify certain aspects of how the other Seque...

...mpared to progress towards the end goal directly. Perhaps not much. - Dave On Sat, Oct 29, 2016 at 8:41 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > An oddity that has existed for a long time in the IR is that PointerType > derives from SequentialType. Per subject I propose to make PointerType > derive from Type for a couple of reasons: > > - Values of type PointerType are unlike the other SequentialTypes (arrays > and vectors) in that they do not hold values of the element type. By moving > PointerType we can unify certain aspect...

...ctorType in the IR Hi, I am helping with the effort to implement scalable vectors in the codebase in order to add support for generating SVE code in the Arm backend. I would like to propose a refactor of the Type class hierarchy in order to eliminate issues related to the misuse of SequentialType::getNumElements(). I would like to introduce a new class FixedVectorType that inherits from SequentialType and VectorType. VectorType would no longer inherit from SequentialType, instead directly inheriting from Type. After this change, it will be statically impossible to accidentally call Sequenti...

...ectly. Perhaps not much. > > - Dave > > On Sat, Oct 29, 2016 at 8:41 PM Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> An oddity that has existed for a long time in the IR is that PointerType >> derives from SequentialType. Per subject I propose to make PointerType >> derive from Type for a couple of reasons: >> >> - Values of type PointerType are unlike the other SequentialTypes (arrays >> and vectors) in that they do not hold values of the element type. By moving >> PointerType we can...

...> > Hi, > > I am helping with the effort to implement scalable vectors in the codebase in order to add support for generating SVE code in the Arm backend. I would like to propose a refactor of the Type class hierarchy in order to eliminate issues related to the misuse of SequentialType::getNumElements(). I would like to introduce a new class FixedVectorType that inherits from SequentialType and VectorType. VectorType would no longer inherit from SequentialType, instead directly inheriting from Type. After this change, it will be statically impossible to accidentally call Sequenti...

...nd goal > directly. Perhaps not much. > > - Dave > > On Sat, Oct 29, 2016 at 8:41 PM Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi all, > > An oddity that has existed for a long time in the IR is that PointerType > derives from SequentialType. Per subject I propose to make PointerType > derive from Type for a couple of reasons: > > - Values of type PointerType are unlike the other SequentialTypes (arrays > and vectors) in that they do not hold values of the element type. By moving > PointerType we can unify certain aspect...

...hris Tetreault via llvm-dev wrote: Hi, I am helping with the effort to implement scalable vectors in the codebase in order to add support for generating SVE code in the Arm backend. I would like to propose a refactor of the Type class hierarchy in order to eliminate issues related to the misuse of SequentialType::getNumElements(). I would like to introduce a new class FixedVectorType that inherits from SequentialType and VectorType. VectorType would no longer inherit from SequentialType, instead directly inheriting from Type. After this change, it will be statically impossible to accidentally call Sequenti...

On Aug 18, 2008, at 4:20 PM, Alireza.Moshtaghi at microchip.com wrote: > This method is defined in: > Lib/VMCore/Type.cpp > And it makes hard assumption that size of integer is 32 or 64. > This gives us trouble because we have 16 bit integer. > Is there a reason for this assumption? Or we can just add the 16-bit > integer to it as well? Hi Alireza, The reason for this is that

This method is defined in: Lib/VMCore/Type.cpp And it makes hard assumption that size of integer is 32 or 64. This gives us trouble because we have 16 bit integer. Is there a reason for this assumption? Or we can just add the 16-bit integer to it as well? Thanks Alireza Moshtaghi Senior Software Engineer Development Systems, Microchip Technology

...your suggestion? Thanks Ali > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Chris Lattner > Sent: Monday, August 18, 2008 4:33 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] hard values in SequentialType::indexValid () method > > > On Aug 18, 2008, at 4:20 PM, Alireza.Moshtaghi at microchip.com wrote: > > > This method is defined in: > > Lib/VMCore/Type.cpp > > And it makes hard assumption that size of integer is 32 or 64. > > This gives us trouble because we...

On Aug 19, 2008, at 6:54 AM, Alireza.Moshtaghi at microchip.com wrote: > What is the reason for getelementptr being tied to only 32 or 64 bit > indexes? As usual, the answer is "that is all anyone has needed so far" :) > Anyways, this is getting in our way. What is your suggestion? Two options: 1) change LLVM IR to allow it, or 2) just insert sign/ zero extension

> Two options: 1) change LLVM IR to allow it, or 2) just insert sign/ > zero extension instructions. > > Does this actually affect the code being generated in practice? Inserting sign/zero extension instructions actually do tend to increase the generated code pretty dramatically on our target. So I prefer option (1) Does this change have dramatic affect on LLVM IR? PS. Currently

On Aug 19, 2008, at 4:14 PM, Alireza.Moshtaghi at microchip.com wrote: >> Two options: 1) change LLVM IR to allow it, or 2) just insert sign/ >> zero extension instructions. >> >> Does this actually affect the code being generated in practice? > > Inserting sign/zero extension instructions actually do tend to > increase > the generated code pretty

> I realize that sign extensions have non-zero impact when they exist in > the .s file. My assertion is that these will be zapped by the dag > combiner. Have you actually tried this? Yes, I have and they work just fine for us. I misunderstood your first email, I thought you are pointing at a problem, while you are actually saying that there is no problem. So back to my original

...es for integer and characters. This > just tells me that parameter is of type pointer or array or structure. > > My question is if function's parameter type is pointer / array, how > can I figure it out whether its character pointer or integer pointer? You need to use dyn_cast<SequentialType> to convert the Type * into a SequentialType *. With that, you can use SequentialType::getElementType() to see what type of pointer type/array type it is. You can also use dyn_cast<> to cast to an ArrayType to get the declared size of the array, or to a StructType so that you can exa...

Hi all, I am working on my Master's project in security and I am trying to iterate over the argument list of the function. Basically I need to do following things : 1. Check data type of each argument of the argument list of the function. 2. Based on its data type like character array or integer array, pointer, int, char, take different action. 3. I have added following code to check its

...return ConstantVector::getSplat(VTy->getNumElements(),00154 getAllOnesValue(VTy->getElementType() When VTy->getNumElements() is called, 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), whichex...

...array. But then again, why not place first-class arrays of appropriate size in such machine registers? Also, at the IR level is there any practical advantage to having vectors not be a kind of array - what does disallowing GEP win you? Is this entirely a codegen issue? By the way, deriving from SequentialType doesn't make much sense to me because SequentialType only exists to unify the types on which you can do GEP (at least that's my understanding) - but you want to disallow GEP on vectors! > > From this point of view you have to allow GEP into a > > vector; the conclusion I suppos...

...dling around a bit with programmatically created GEP instructions, which is failing when using i64 for any indix, except the first. The reason behind this, is that StructureType::indexValid only accepts Value* that are constant ints of width 32. I can't really see why this limitation is here. SequentialType solves this slightly differently, it allows for both 32 and 64 bits integers. However, AFAICS, any constant 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...