search for: constantvectors

Hi! currently instcombine does not detect constant diagonal matrix times vector, for example a.xx * [2 0] + a.yy * [0 3] can be optimized to a * [2 3] I have implemented this for float. I know that this assumes x * 0 = 0 which is not ieee compliant but i post it here in case it is interesting for someone. on my wish list there is still an option for target independent optimizations to have x

Hi Anton, >> you can't, you can only get a ConstantAggregateZero. This is actually kind of >> annoying, and means that places expecting a ConstantArray have to remember to >> also check for ConstantAggregateZero. Perhaps there's a good reason for the >> current design, but if not it would be great to eliminate this wart. > Well, I think the main reason it so

> you can't, you can only get a ConstantAggregateZero.  This is actually kind of > annoying, and means that places expecting a ConstantArray have to remember to > also check for ConstantAggregateZero.  Perhaps there's a good reason for the > current design, but if not it would be great to eliminate this wart. Well, I think the main reason it so reduce the size of .ll / .bc when

----- Original Message ----- > Hi, > > I noticed that ConstantFP::get automatically returns the > appropriately > types Constant depending on the LLVM type passed in (i.e. if called > with a vector, it returns a splat vector with the given constant). > > Is there any simple way to do the inverse of this function? i.e., > given a llvm::Value, check whether it is either

Hi all. I propose to use wrapper for this kind of constant objects. Consider next code: Constant* C = reinterpret_cast<Constant*>(I->getOperand(idx)); Constant* ArrayItem; if (!isa<ConstantAggregateZero>(C)) ArrayItem = reinterpret_cast<Constant*>(I->getOperand(ArrItemIdx)); else ArrayItem = ZeroInt; Code analog within wrapper: ConstOrZero

Hi, I noticed that ConstantFP::get automatically returns the appropriately types Constant depending on the LLVM type passed in (i.e. if called with a vector, it returns a splat vector with the given constant). Is there any simple way to do the inverse of this function? i.e., given a llvm::Value, check whether it is either a scalar of the given constant value or a splat vector with the given

I'd really rather not do this. Faking that large zero filled array is represented with ConstantArray means that the compiler will inevitably end up calling getOperand on each of those elements, burning a ton of compile time. -Chris On Jan 20, 2012, at 12:16 PM, Stepan Dyatkovskiy <STPWORLD at narod.ru> wrote: > Hi all. I propose to use wrapper for this kind of constant objects.

Hi Chris, this was a very tempting commit to make, unfortunately it broke pattern matching of vectors of booleans. The problem is that a ConstantDataVector is only formed if the element type is one of i8, i16, etc. So vectors of funky types, or not so funky types like i1, are no longer matched. I noticed this while working on PR11948. The good thing is that the testcase there no longer crashes

r261464 added a type called ConstantData to the Value hierarchy. This is a parent type for constants with no operands, such as i32 0 and null. Since then, I've removed most instances of iterating through the use-lists of an instance of ConstantData. I'd like to make this illegal. Since the users of ConstantData are spread across an LLVMContext, most code that looks at the users is

On Feb 9, 2012, at 1:22 PM, Duncan Sands wrote: > Hi Chris, this was a very tempting commit to make, unfortunately it broke > pattern matching of vectors of booleans. The problem is that a > ConstantDataVector is only formed if the element type is one of i8, i16, etc. > So vectors of funky types, or not so funky types like i1, are no longer > matched. I noticed this while working

Hi Chris, >> Hi Chris, this was a very tempting commit to make, unfortunately it broke >> pattern matching of vectors of booleans. The problem is that a >> ConstantDataVector is only formed if the element type is one of i8, i16, etc. >> So vectors of funky types, or not so funky types like i1, are no longer >> matched. I noticed this while working on PR11948. The

Hi all. I'm working on patch and I'm using unchangable ConstantInt objects. So everywhere I'm using "const ConstantInt*". But this idea came to deadlock after I tried to create ConstantVector using my vector<const ConstantInt*> collection. All because of next form of ConstantVector::get: // Note: ArrayRef declared with non-constant Constant* object. Constant

Sorry!  Forgot to CC the list. ----- Forwarded Message ----- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Stepan Dyatkovskiy <stpworld at narod.ru> > Cc: > Sent: Wednesday, January 18, 2012 1:31 PM > Subject: Re: [LLVMdev] Should the Constant* pointer be declared with "const" or not? > > Hello Stepan, > > The LLVM source code uses a

Try to keep things on the mailing list, if possible.  That usually means hitting "reply to all".  (I forgot earlier, myself.  Sorry.) ----- Forwarded Message ----- > From: Stepan Dyatkovskiy <STPWORLD at narod.ru> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: > Sent: Wednesday, January 18, 2012 1:50 PM > Subject: Re: [LLVMdev] Should the Constant*

> On 2016-Sep-24, at 15:16, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Sep 24, 2016, at 3:06 PM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> r261464 added a type called ConstantData to the Value hierarchy. This >> is a parent type for constants with no operands, such as i32 0 and null. >>

On Jul 26, 2011, at 9:17 PM, Talin wrote: > Here's an example of how this would be used: In the constructor for ConstantVector, there's an assert: > > assert(C->getType() == T->getElementType() && > "Initializer for vector element doesn't match vector element type!"); > > I would change this to: > >

The methods for constructing constant sequencish types (struct, array, vector) aren't consistent and we are missing a few useful convenience methods. I would like to change the interfaces to each support four construction methods: (a) With and without a type. (b) With a vector or an array + size. Here: -- ConstantStruct { static Constant *get(const StructType *T,

I notice that there's a lot of inconsistency in the various LLVM classes with respect to convenience methods. Here's some examples: For creating GEPS, IRBuilder has: CreateGEP (2 overloads) CreateInBoundsGEP (2 overloads) CreateConstGEP1_32 CreateConstInBoundsGEP1_32 CreateConstGEP2_32 CreateConstInBoundsGEP2_32 CreateConstGEP1_64 CreateConstInBoundsGEP1_64

Here's an example of how this would be used: In the constructor for ConstantVector, there's an assert: assert(C->getType() == T->getElementType() && "Initializer for vector element doesn't match vector element type!"); I would change this to: ASSERT_STRM(C->getType() == T->getElementType(), "Initializer for vector element "

On Mon, Mar 15, 2010 at 11:51:47AM +0000, Tim Northover wrote: > Hello, > > I noticed a bit of a gap in the current code for unions: a > ConstantUnion cannot be written out to .ll. I've been continuing plugging gaps as I find them, which might not be the best way to solve this problem, but it has produced something that seems to do roughly what I expect. I've split it into