similar to: 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

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

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

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.

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

Does anyone know how to instrument *double* to <2 x doulbe>**, e.g., 2.2 --> <2.2, 2.2>? For example, I want to change the following IR code %arrayidx1 = getelementptr inbounds [100 x double]* @main.B, i32 0, i32 %i.021 %1 = load double* %arrayidx1, align 4, !tbaa !0 to: %arrayidx1 = getelementptr inbounds [100 x double]* @main.B, i32 0, i32 %i.021 %1 = bitcast double* %arrayidx1

On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > > Tobias, > > > > I've attached an updated patch. It contains a few bug fixes and many > > (refactoring and coding-convention) changes inspired by your comments. > > > > I'm currently trying to fix the bug responsible for causing a compile

On 11/23/2011 05:52 PM, Hal Finkel wrote: > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: >>> > > Tobias, >>> > > >>> > > I've attached an updated patch. It contains a few bug fixes and many >>> > > (refactoring and coding-convention) changes inspired

On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > Tobias, > > I've attached an updated patch. It contains a few bug fixes and many > (refactoring and coding-convention) changes inspired by your comments. > > I'm currently trying to fix the bug responsible for causing a compile > failure when compiling >

Thanks Nick, that's something what I am trying to implement as the following. But it seems I still only get the constant value not the instruction. Could you please go over the following instruction and see what wrong with it? Thanks for your time again. Value *vecVal = NULL; IRBuilder<> builder(&*pInst); Type *vecTy = VectorType::get(Type::getDoubleTy(ctxt), 2); Value

I got it. Thanks, Nick. So, it is back to the previous problem. If I have the following instruction: %3 = fadd double %1, double %2 I want to change it into %6 = fadd <2 x double> %4, double %5 where %4 = <double %1, double %1>, %5 = <double %2, double %2>, how can I do this? Thanks, Best On Fri, Apr 17, 2015 at 1:56 AM, Nick Lewycky <nicholas at mxc.ca> wrote: >

Hi Tom, Hi Anton, the first I had in mind was... "Another (LLVM/CLang) realease - a new drama!" ( See Byron Katie "The work". ) I know SVN is your 1st development platform. Personally, I prefer Git and use the LLVM/Clang mirrors on GitHub. Unfortunately, I am missing a "release_381" branch at all on the GitHub repositories. I looked through the llvm-commits [1]

Please have a look at the dedicated mailing list: http://lists.llvm.org/pipermail/llvm-branch-commits/ Please wait for the official release to happen, you will then find tarballs on llvm.org. They will also contain correct version strings, though I haven't yet tried building from the SVN branches directly. Maybe you need to use the SVN tags, $ clang --version currently gives me "clang

>>> What you're probably missing is that 3.8.1 is made in release_38 >>> branch. So, everything is there and already mirrored. >>> >>> Source tarballs will be available upon the release. >> Which are just coming, now that final has been tested successfully. :) >> They'll be announced in the list and available here: >>

On Mon, Jun 27, 2016 at 9:12 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >>>> What you're probably missing is that 3.8.1 is made in release_38 >>>> branch. So, everything is there and already mirrored. >>>> >>>> Source tarballs will be available upon the release. >>> Which are just coming, now that final has been

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

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

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

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

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