search for: constantdatavector

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 the compiler because earlier patterns now fail to match...

Does anybody else have an opinion on this issue? I'm planning to submit a patch which would add a new get method for ConstantDataVector taking an ArrayRef<Constant*> and use that in the few places in constant propagation where convertToFloat is used. Let me know if you think there is a more obvious way to do it. Right now the only way to create a ConstantDataVector are those method: /// get() constructors - Return a con...

I don't see a way to create a ConstantDataVector from Constant or form APFloat though. Did I oversee that? Is the solution to had a new get function in ConstantDataVector to allow that? Any hint on what would be the right fix otherwise? Thomas -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednes...

...a parameter and check that the value is of a constant of the appropriate type and value (checking for vectors matching the predicate in the vector case). For example: static bool ConstantFP::isExactlyValue(Value *V, double D); would return true is V is ConstantFP, a splat ConstantVector, or a ConstantDataVector with the appropriate type. Similarly, static bool ConstantFP::isZero(Value *V); would return true if V is a ConstantFP with zero of either sign, a ConstantVector or ConstantDataVector with all zeros of either sign, or a zero initializer... Anyone have any thoughts, and/or can point me to some...

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 on PR11948. The good thing is that > the testcase there no longer crashes the compiler because earlier patterns &gt...

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 good thing is that >> the testcase there no longer crashes the compiler because earlier...

...do this: if (const ConstantVector *CV = dyn_cast<ConstantVector>(X)) if (Constant *Splat = CV->getSplatValue()) // Now you know that Splat is a splatted value, so check it for something. -Hal > > would return true is V is ConstantFP, a splat ConstantVector, or a > ConstantDataVector with the appropriate type. Similarly, > > static bool ConstantFP::isZero(Value *V); > > would return true if V is a ConstantFP with zero of either sign, a > ConstantVector or ConstantDataVector with all zeros of either sign, > or > a zero initializer... > > Anyone h...

...a constant of the appropriate > type and value (checking for vectors matching the predicate in the > vector case). > > For example: > > static bool ConstantFP::isExactlyValue(Value *V, double D); > > would return true is V is ConstantFP, a splat ConstantVector, or a > ConstantDataVector with the appropriate type. Similarly, > > static bool ConstantFP::isZero(Value *V); > > would return true if V is a ConstantFP with zero of either sign, a > ConstantVector or ConstantDataVector with all zeros of either sign, or > a zero initializer... > > Anyone have any...

Ha here is what I was missing. Thanks Jon. It still seems to me that the transformation of LLVM IR is invalid is that right? I assume we shouldn't be converting APFloat to float in order to avoid such problems? -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 9:39 AM To: Raoux, Thomas F; LLVM Developers Mailing List

Hi all, I have a very simple test case (thanks to bugpoint) that hit an assert in reassociate. (the assert is (C->getType()->isIntOrIntVectorTy() && "Cannot NEG a nonintegral value!"), function getNeg) The function is taking a Constant as argument, but the assert does not expect an undef. I’m not sure whose responsibility is it to handle that (caller?). Do we have to

...-py should be changed to consistent with these modified API. a. IR Type system. IR type system is reimplemented LLVM 3. For instance, * OpaqueType* are gone. Such type should also be removed in llvm-py. b. Value class. Two new sub classes of Value are added: *ConstantDataArray*, an array constant *ConstantDataVector*, a vector constant. llvm-py should contain them. c. Instruction class. Four new sub classes of Instruction are added: *FenceInst*, an instruction for ordering other memory operations; *AtomicCmpXchgInst*, an instruction that atomically checks and exchanges values in a memory location; *AtomicRMWIn...

Fantastic! It's working! Thank you so much Craig!!! On Fri, Apr 7, 2017 at 6:05 PM, Craig Topper <craig.topper at gmail.com> wrote: > It should be VectorType::get(Type::getInt32Ty(Context),4). You need the > word "get" after VectorType:: > > ~Craig > > On Fri, Apr 7, 2017 at 6:01 PM, Michael Choi <choimichael103 at gmail.com> > wrote: >