similar to: [LLVMdev] Get a vector value.

Displaying 20 results from an estimated 400 matches similar to: "[LLVMdev] Get a vector value."

2011 Nov 14
2
[LLVMdev] Transferring value* in LLVM
Here is the error that I get: Assertion failed: (i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!" Yakov On Mon, Nov 14, 2011 at 9:05 PM, Eric Christopher <echristo at apple.com>wrote: > You'll probably need to dump both the source and the dest and show the > code that's being
2011 Nov 14
2
[LLVMdev] Transferring value* in LLVM
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 reasons for such error? > > The only
2011 Nov 14
1
[LLVMdev] Transferring value* in LLVM
So what do you think the problem is? Thank you. Yakov On Mon, Nov 14, 2011 at 10:20 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 21:11, Yakov Malinkovich wrote: > >> Here is the error that I get: >> Assertion failed: (i >= FTy->getNumParams() || FTy->getParamType(i) == >> Params[i]->getType()) && "Calling a function with a
2011 Nov 14
0
[LLVMdev] Transferring value* in LLVM
On 14/11/11 21:11, Yakov Malinkovich wrote: > Here is the error that I get: > Assertion failed: (i >= FTy->getNumParams() || FTy->getParamType(i) == > Params[i]->getType()) && "Calling a function with a bad signature!" That's not being generated by the CreateCast, so it looks like your description of the problem was quite misleading. Ciao, Duncan. >
2011 Nov 14
2
[LLVMdev] Transferring value* in LLVM
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. > > >
2011 Nov 14
0
[LLVMdev] Transferring value* in LLVM
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
2012 May 04
2
[LLVMdev] Convert a vector size
> %temp = shufflevector <3 x i16> %incoming, <3 x i16> undef, <4 x i32> > <i32 0, i32 1, i32 2, i32 undef> > %out = bitcast <4 x i16> %temp to i64 I seem to have misread the destination type, you'd obviously want "<1 x i64>" instead of "i64" in everything I've written. Tim.
2012 May 04
0
[LLVMdev] Convert a vector size
I have a function that should work only with vector types having element type as a power of 2. So if I get total 48 bit vector I should force it to be rounded to total 64 bit vector Yakov On Fri, May 4, 2012 at 10:37 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > > %temp = shufflevector <3 x i16> %incoming, <3 x i16> undef, <4 x i32> > >
2011 Dec 13
1
[LLVMdev] Changing the operands in the CallInst
I implement the following function,which gets CallInst * and should perform the following: 1. Change the value of the argument if condition1 takes place 2. Change the type of the argument if condition2 takes place 3. Add addition argument/s if condition3 takes place void argChange(CallInst * I) { for (unsigned index = 0; index < I->getNumOperands(); ++index) {
2011 Nov 14
0
[LLVMdev] Transferring value* in LLVM
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 >
2011 Nov 14
2
[LLVMdev] Transferring value* in LLVM
It doesnt work it fails with assertation that cast is invalid .What could be done? On 11/14/11, Duncan Sands <baldrick at free.fr> wrote: > Hi Yakov, that looks correct to me. You can also use CreateFPExt which is > slightly simpler. > > Ciao, Duncan. > > >> I want to transfer value (Value* src) of the type `FloatTyID` to >> `DoubleTyID`(I >> need all
2011 Nov 14
0
[LLVMdev] Transferring value* in LLVM
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. > > > On 11/14/11, Duncan Sands<baldrick at free.fr> wrote: >> Hi Yakov, that looks correct to me. You can also use CreateFPExt which is >> slightly simpler. >> >>
2020 Apr 22
2
[Update][RFC] Refactor class hierarchy of VectorType in the IR
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
2020 May 05
2
[Update][RFC] Refactor class hierarchy of VectorType in the IR
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
2020 May 21
3
[RFC] Refactor class hierarchy of VectorType in the IR
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.
2020 Mar 09
8
[RFC] Refactor class hierarchy of VectorType 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
2008 Jul 16
3
[LLVMdev] GEP::getIndexValid() with other iterators
Hi all, currently, GetElementPtrInst has a method getIndexedType, which has a templated variant. You pass in a begin and an end iterator, and it will find the indexed type for those. However, both iterators must iterate over Value*. For some argpromotion code, I would like to pass in iterators that iterate over unsigneds instead of Value*. I currently solve this by transforming my
2012 Sep 05
1
[LLVMdev] Calling a function with a pointer to a global char array as argument
Hello; Thanks to Eli for the pointer to the ConstantDataArray::getString() fucntion. Now I am trying to declare a global char array with the content "hi" and call a function "print" (which takes a char pointer and return an insteger. I am doing the following in the code - Function Creation: PointerType* array = PointerType::get(IntegerType::getInt8Ty(getGlobalContext())
2008 Jul 23
0
[LLVMdev] GEP::getIndexValid() with other iterators
Hi Chris, > What flavor of iterators do you want to pass in? vector or > smallvector? If so, a pointer to the first element + extents is fine. I was passing a std::vector in. And you are quite right, first element + size works like a charm. Since I am using a vector of uint64_t's instead of Value*, I did need to add an extra version of getIndexedType(), taking a uint64_t* instead
2008 Jul 16
0
[LLVMdev] GEP::getIndexValid() with other iterators
Hi all, once more with the patch inline for easy review. I did not include the argpromotion pass here, since it's not the main topic of this post. Gr. Matthijs Index: lib/VMCore/Instructions.cpp =================================================================== --- lib/VMCore/Instructions.cpp (revision 53672) +++ lib/VMCore/Instructions.cpp (working copy) @@ -1068,41 +1068,6 @@