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 @@