search for: sequentialtypes

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

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 SequentialTypes are handled. - PointerType will have no place in the SequentialType hierarchy once pointee types are removed, so this is a necessary step tow...

...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 aspects of how the other SequentialTypes > are handled. > - PointerType will have no place in the SequentialType hierarchy once > pointee types are removed, so thi...

Hi, I just wanted to give an update on the progress of this work. This morning I merged a patch to add the new vector types. I have added a FixedVectorType, as proposed below. I also added a ScalableVectorType. I found during my work that it is useful to be able to query isa<ScalableVectorType>(Ty). Additionally, I was concerned that it would become commonplace to take

...; 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 SequentialTypes >> are handled. >> - PointerType will have no place in the SequentialType hierarchy once >> pointee types...

Nicolai, My plan is to remove getNumElements() as soon as possible. Hopefully within the next few weeks. I just made a patch on my machine that marks it deprecated, and it generates a ton of warnings. Given that some build bots build with -Werror, I don't think we can mark it deprecated unless all the usages are first removed. It occurs to me now that it might be good to mark it

....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 aspects of how the other SequentialTypes > are handled. > - PointerType will have no place in the SequentialType hierarchy once > pointee types are removed, so thi...

Hi John, I’d like to address some points in your message. > Practically speaking, this is going to break every out-of-tree frontend, backend, or optimization pass that supports SIMD types. My understanding is that the policy in LLVM development is that we do not let considerations for downstream and out-of-tree codebases affect the pace of development. The C++ API is explicitly unstable.

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

What is the reason for getelementptr being tied to only 32 or 64 bit indexes? It seems to me that integer size would be better choice... Anyways, this is getting in our way. What is 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

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

On 2/25/13 1:44 PM, teja tamboli wrote: > 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 : Interesting. Just out of curiosity, can you tell us what your project is about? > > 1. Check data type of each argument of the argument list of the

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

Hi, I was playing with the Constant::getAllOnesValue() method and found that it doesn't handlesPointerTypes correctly. When receiving a "i32*" argument, it was returning with some big integer vector, such as <12113216 x i32>. When you call this method passing a PointerType, the following code is executed: 00152 VectorType *VTy = cast<VectorType>(Ty);00153 return

Hi Chris, > I'm happy about factoring the code better, but a vectortype isn't an > arraytype (isa<ArrayType>(V) should be false). Maybe a common base > class (like sequential type) would be better? currently anything you can do with an array you can do with a vector. So from this functional viewpoint it would make sense to have a vector be an array with more stuff

Hi all, I'm fiddling 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