similar to: [LLVMdev] function creation question

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] function creation question"

2018 Feb 15
2
package MonteCarlo error: object 'packages' not found
R-users, I can't tell what's causing the following error. The vignette does not make a reference to a "packages" option or parameter. > library(MonteCarlo) Loading required package: abind Loading required package: codetools Loading required package: rlecuyer Loading required package: snow Loading required package: snowfall > infest_kud_fun<-function(x,A,B){ +??
2018 Jul 20
2
LLVM FunctionType cannot be returned as VectorType?
Dear all, I am using LLVM C++ API to generate some code. In particular, I am dealing with AVX2 SIMD API which uses __m256i. My function input types a set of vectors and return type is also a vector. /////////////////////////////////////////////////////////////////////////////////////////// arguments.push_back(VectorType::get(IntegerType::getIntNTy(TheContext, 64), 4));//int64*4 = __m256i
2018 Feb 15
0
package MonteCarlo error: object 'packages' not found
This looks like the sort of thing that you should ask the package maintainer (?maintainer). Cheers, Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Thu, Feb 15, 2018 at 11:39 AM, john polo <jpolo at mail.usf.edu> wrote: >
2008 Jan 04
7
[LLVMdev] Calling functions across modules. And those pesky vectors!
Before I get started with more questions, thanks for the prompt reply on my last set question, that was much appreciated. First, I found references to lazy inling and optimizations for calling functions across modules, but I can't figure out how to do that. If I just take a Function* that I got out of one module and call it from the other, it doesn't work. What's the general
2018 Jul 23
2
LLVM FunctionType cannot be returned as VectorType?
Hi Joshua, Thanks for your great comment. I made up a ConstantVector in IR. Then I successfully use AVX intrinsics to retrieve the returned vector data. The remaining thing is that how to pass the vectors to LLVM function using intrinsics. Do you have any suggestions? Please forgive me if the question is too naive. I pasted below two IR I used. The first one works. The second one doesn't.
2018 Jul 23
2
LLVM FunctionType cannot be returned as VectorType?
Hi Stefan, Thank you very much for answering my question! I followed your suggestion but the function still cannot return the correct result. I also set target-feature attributes for my function. I am using LLVM 6.0. It only prints out some random large numbers but the correct answer is supposed to be all 0. Can you please help me figure out what's going on here? Any help will be greatly
2020 May 22
3
[RFC] Refactor class hierarchy of VectorType in the IR
John, For the last several months, those of us working on the scalable vectors feature have been examining the codebase, identifying places where llvm::VectorType is used incorrectly, and fixing them. The fact is that there are many places where VectorType is correctly taken to be the generic “any vector” type. getNumElements may be being called, but it’s being called in accordance with the
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 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
5
[RFC] Refactor class hierarchy of VectorType in the IR
John, > This is not categorically true, no. When we make changes that require large-scale updates for downstream codebases, we do so because there’s a real expected benefit to it. For the most part, we do make some effort to keep existing source interfaces stable. While I’m at a loss to find a documented policy, I recall this thread
2017 Apr 08
2
How to insert vector type input parameter for function in C/C++ API?
Thank you so much Craig! I tried it. But still complaining. Here is the error message during compilation. HowToUseJIT_SIMD_FuncProto.cpp:94:55: error: expected unqualified-id VectorType::(Type::getInt32Ty(Context),4), THIS IS MY CODE: LLVMContext Context; std::unique_ptr<Module> Owner = make_unique<Module>("test", Context); Module *M = Owner.get(); Function
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
2017 Apr 08
3
How to insert vector type input parameter for function in C/C++ API?
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: >
2020 Jul 16
2
BitcodeReader.cpp bug under LTO
Hi guys, We have found a bug of BitcodeReader.cpp in processing an LTO bitcode file. As LLVM doesn't emit use-list for LTO bitcode files, many forward references will happen when BitcodeReader processes the bitcode file, and LLVM uses placeholders for those forward references and resolve them later. When parseConstants() reads in a CST_CODE_CE_SELECT record, e.g. select
2012 Jun 03
1
[LLVMdev] Constant::getAllOnesValue(): expected behaviour or bug?
Hi, I was playing with the Constant::getAllOnesValue() method and found that it doesn't handlesPointerTypes correctly. When receiving a "i32*" argument, it was returning with some big integer vector, such as <12113216 x i32>. When you call this method passing a PointerType, the following code is executed: 00152 VectorType *VTy = cast<VectorType>(Ty);00153 return
2020 May 13
3
[llvm-commits@lists.llvm.org: Re: [llvm] 2dea3f1 - [SVE] Add new VectorType subclasses]
Regarding the numerical value of the LLVMTypeKind enum, my understanding is that LLVM-C does not promise to maintain ABI compatability between versions. If I am mistaken, I can fix this issue. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of James Y Knight via llvm-dev Sent: Wednesday, May 13, 2020 7:33 AM To: Joerg Sonnenberger <joerg at bec.de>; llvm-dev <llvm-dev
2017 Jul 06
2
[RFC][SVE] Supporting Scalable Vector Architectures in LLVM IR (take 2)
[Sending again to list] Hi Chris, Responses inline... On 6 July 2017 at 21:02, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks for sending this out Graham. Here are some comments: > > This is a clever approach to unifying the two concepts, and I think that the approach is basically reasonable. The primary problem that this will introduce is: >
2020 Jul 20
2
BitcodeReader.cpp bug under LTO
Hi Eli, Thanks for the advice! By delaying processing the "select" until we have resolved other records(like "aggregate " in this case) as you did for "shuffle", the test case passes now. But I wonder if it's an ultimate solution: what if the selector of a "select" is the output of another forward-reference "select" that hasn't been
2020 May 13
4
[llvm-commits@lists.llvm.org: Re: [llvm] 2dea3f1 - [SVE] Add new VectorType subclasses]
Bringing this up on llvm-dev for more general attention. The problem here is two fold: (1) Reuse of enumeration values is just a major no-go. (2) I'm not sure why the existing vector types had to be killed completely. But something clearly has to be done here. This majorly affects e.g. Mesa. Joerg ----- Forwarded message from Joerg Sonnenberger via llvm-commits <llvm-commits at