search for: isfloatty

yes - i checked that the src->getType()->isFloatTy() is true Yakov On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 19:20, Yakov Malinkovich wrote: > >> I sure that is. >> > > Did you test it? Can you do: src->getType()->isFloatTy() > > > What could be other re...

...mp both the source and the dest and show the > code that's being generated. A lot of guessing here that's not getting us > very far very fast. > > -eric > > > On Nov 14, 2011, at 10:56 AM, Yakov Malinkovich wrote: > > yes - i checked that the src->getType()->isFloatTy() is true > Yakov > > > On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick at free.fr> wrote: > >> On 14/11/11 19:20, Yakov Malinkovich wrote: >> >>> I sure that is. >>> >> >> Did you test it? Can you do: src->getType()->isF...

You'll probably need to dump both the source and the dest and show the code that's being generated. A lot of guessing here that's not getting us very far very fast. -eric On Nov 14, 2011, at 10:56 AM, Yakov Malinkovich wrote: > yes - i checked that the src->getType()->isFloatTy() is true > Yakov > > > On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 19:20, Yakov Malinkovich wrote: > I sure that is. > > Did you test it? Can you do: src->getType()->isFloatTy() > > > What could be othe...

On 14/11/11 19:20, Yakov Malinkovich wrote: > I sure that is. Did you test it? Can you do: src->getType()->isFloatTy() What could be other reasons for such error? The only other possibility I can think of is that src was created using a different context. Ciao, Duncan. > Yakov > > > On Mon, Nov 14, 2011 at 5:44 PM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wr...

...he dest and show the code > that's being generated. A lot of guessing here that's not getting us very > far very fast. > > -eric > > > On Nov 14, 2011, at 10:56 AM, Yakov Malinkovich wrote: > >> yes - i checked that the src->getType()->isFloatTy() is true >> Yakov >> >> >> On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick at free.fr >> <mailto:baldrick at free.fr>> wrote: >> >> On 14/11/11 19:20, Yakov Malinkovich wrote: >> >> I sure tha...

...that's being generated. A lot of guessing here that's not getting us >> very >> far very fast. >> >> -eric >> >> >> On Nov 14, 2011, at 10:56 AM, Yakov Malinkovich wrote: >> >> yes - i checked that the src->getType()->isFloatTy() is true >>> Yakov >>> >>> >>> On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick at free.fr >>> <mailto:baldrick at free.fr>> wrote: >>> >>> On 14/11/11 19:20, Yakov Malinkovich wrote: >>> &gt...

...e to be changed. I'm not entirely positive why the float value returned by converToFloat has a different memory representation than the original int value, there must be a C++ rule that I'm missing. d if (ConstantFP *CFP = dyn_cast<ConstantFP>(C)) { if (CFP->getType()->isFloatTy()) { SmallVector<float, 16> Elts; for (unsigned i = 0, e = V.size(); i != e; ++i) if (ConstantFP *CFP = dyn_cast<ConstantFP>(V[i])) Elts.push_back(CFP->getValueAPF().convertToFloat()); else break; if (Elts.size() ==...

I sure that is.What could be other reasons for such error? Yakov On Mon, Nov 14, 2011 at 5:44 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 16:39, Yakov Malinkovich wrote: > >> It doesnt work it fails with assertation that cast is invalid .What >> could be done? >> > > Maybe src doesn't have Float type? > > Ciao, Duncan. > > >

...pear first in the layout of the types. The format of the real and imaginary parts is the same as for float and double, respectively. This should map to most common data representations of complex in various languages. These types are *not* considered floating point types for the purposes of Type::isFloatTy and friends, llvm_anyfloat_ty, etc. in order to limit surprises when introducing these types. New APIs will allow querying and creation of complex types: bool Type::isComplexTy() const; bool Type::isComplex32Ty() const; bool Type::isComplex64Ty() const; Analogous ValueTypes will be used by...

Hi all, can I access the numeric limits of the llvm types, e.g. HalfTy, FloatTy, DoubleTy, etc. in a fashion like the std numeric_limits tool? std::numeric_limits<half>::min() std::numeric_limits<half>::max() In c++API, I want to initialize values and need to know the correct range for the llvm types.... Thx Alex

...ve why the float > value returned by converToFloat has a different memory representation > than the original int value, there must be a C++ rule that I'm missing. > > d > > if (ConstantFP *CFP = dyn_cast<ConstantFP>(C)) { > > if (CFP->getType()->isFloatTy()) { > > SmallVector<float, 16> Elts; > > for (unsigned i = 0, e = V.size(); i != e; ++i) > > if (ConstantFP *CFP = dyn_cast<ConstantFP>(V[i])) > > Elts.push_back(CFP->getValueAPF().convertToFloat()); > >...

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:

...t in the layout of the types. The format of the real and imaginary parts is the same as for the complex type's underlying type. This should map to most common data representations of complex in various languages. These types are *not* considered floating point types for the purposes of Type::isFloatTy and friends, llvm_anyfloat_ty, etc. in order to limit surprises when introducing these types. New APIs will allow querying and creation of complex types: bool Type::isComplexTy() const; bool Type::isComplex16Ty() const; bool Type::isComplex32Ty() const; bool Type::isComplex...

...t in the layout of the types. The format of the real and imaginary parts is the same as for the complex type's underlying type. This should map to most common data representations of complex in various languages. These types are *not* considered floating point types for the purposes of Type::isFloatTy and friends, llvm_anyfloat_ty, etc. in order to limit surprises when introducing these types. New APIs will allow querying and creation of complex types: bool Type::isComplexTy() const; bool Type::isComplex16Ty() const; bool Type::isComplex32Ty() const; bool Type::isComplex...

...The > format of the real and imaginary parts is the same as for the complex type's > underlying type. This should map to most common data representations of complex > in various languages. > > These types are *not* considered floating point types for the purposes of > Type::isFloatTy and friends, llvm_anyfloat_ty, etc. in order to limit surprises > when introducing these types. New APIs will allow querying and creation of > complex types: > > bool Type::isComplexTy() const; > bool Type::isComplex16Ty() const; > bool Type::isComplex32Ty()...