search for: instrinsics

...- Arnaud de Grandmaison -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101203/b1d97bbf/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: metadata-target-instrinsics.patch Type: application/octet-stream Size: 1633 bytes Desc: metadata-target-instrinsics.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101203/b1d97bbf/attachment.obj>

I want to create a vector version sqrt as the following. Value *Approx::CreateFSqrt(IRBuilder<> &builder, Value *v, const char* Name) { Type *tys[] = {v->getType()}; Module* M = currF->getParent(); Value* sqrtv = Intrinsic::getDeclaration(M, Intrinsic::x86_sse2_sqrt_pd); CallInst *CI = builder.CreateCall(sqrtv, v, Name); return CI; } Here is Value *v is <2 x

Hi: I want add new Instrinsic for my target. So I first do some test. I add them in IntrinsicsPowerPC.td //===--------------------===// let TargetPrefix = "ppc" in { def int_ppc_mytest : Intrinsic<[llvm_void_ty], [], [IntrWriteMem]>; } //===--------------------===// I add them in PPCInstrInfo.td //===--------------------===// def MYTEST : XForm_24_sync<31, 599, (outs), (ins),

...tType()); > > > > Regards, > > Shahid > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *zhi chen > *Sent:* Saturday, April 18, 2015 5:52 AM > *To:* LLVM Dev > *Subject:* [LLVMdev] how can I create an SSE instrinsics sqrt? > > > > I want to create a vector version sqrt as the following. > > > > Value *Approx::CreateFSqrt(IRBuilder<> &builder, Value *v, const char* > Name) { > > Type *tys[] = {v->getType()}; > > Module* M = currF->getParent(); > >...

Dear Developers, I compiled a OpenCL kernel before (on Nov. last year) like __kernel void g(__global float* array) { array[get_global_id(0)] = 1; } with libclc, which would originally use the instrinsics like llvm.r600.read.local.size.x(). I executed the generated object file with one version of the hsa-runtime [1] provided by Mr. Stellard, when there was more than one workgroup, the output of the program wasn't correct at that time. I guessed this might be because get_group_id() always return...

On 4/14/11 6:34 PM, Kodakara, Sreekumar V wrote: > > Hi All, > > I have a question on ConstantExpressions and llvm intrinsic > memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C > programs that I am compiling using clang frontend, the call to memcpy > instrinsic looks like the following > > call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast

Hi All, I have a question on ConstantExpressions and llvm intrinsic memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C programs that I am compiling using clang frontend, the call to memcpy instrinsic looks like the following call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast (%struct.ta* @tret to i8*), i64 4, i32 4, i1 false), !dbg !19 The second argument to memcpy is

I am getting the following error when i am trying to generate the code. In the optimization pass I have inserted some calls llvm.annotation.i32 class to provide indentification tags to loops to be used in subsequent passes. Codegen is complaining about these annotations. llc -march=c ham1_seq.bc3 Error: Code generator does not support intrinsic function 'llvm.annotation.i32'! llc

Hello, I'm currently looking into integrating the patchpoint and stackmap intrinsics into my pet project. In their current implementation (3.4 and trunk) the code to emit the additional section is only executed on Darwin. This is however quickly fixed: Add a ".llvm_stackmaps"-Section for ELF in MCObjectFileInfo and execute StackMaps::serializeToStackMapSection in X86AsmPrinter in

> I'm trying to understand how the non-LTO case is supposed to work non-LTO case works because when linker starts it’s job all the llvm intrinsics are already lowered. > Right, which is why I am suggesting that it might be appropriate to build with -fno-builtin (or -fno-builtin-exp) here – > this solves the LTO issue as there will no longer be an llvm intrinsic in the bitcode Yes, I

There are a few instrinsic functions I would like to remove, is this possible? For example, the llvm.lifetime and llvm.dbg instrinsics? You can't simply iterate over the funciton and remove the call instructions, this causes issues. Is there a known structured way of doing this? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120328/4b3...

Hi,all. I've been reading the llvm source code for some days. Here is my problem: what does instrinsic / intrinsic function really means? Are these "the function belong to llvm and just belong to llvm"? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...patibility would be appropriate. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Craig Topper via llvm-dev Sent: Wednesday, September 20, 2017 1:01 PM To: Daniel Berlin Cc: llvm-dev Subject: Re: [llvm-dev] RFC: [X86] Can we begin removing AutoUpgrade support for x86 instrinsics added in early 3.X versions Many of the older autoupgrades have no test cases because I think when we upgraded them we just replace all the code in the tests with native IR. So for some of the code we don't even know if it works. I don't really want to watch the amount of code here contin...

Is there a reason why? IE is it hard to maintain, slow, or are you just worried it will break? or something else? (I'm not opposed in any way, literally just want to understand the motivation) On Wed, Sep 20, 2017 at 12:20 PM, Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics > that have

+pcc for thoughts On Fri, Mar 23, 2018 at 9:37 AM, Bakhvalov, Denis <denis.bakhvalov at intel.com > wrote: > Hello Teresa, > > > > > Without -flto, a.o ends up with a reference to __exp_finite, > > That’s correct. > > > > > which also would not be satifisfied out of libexp.a. > > That’s not correct. Even if libexp.a would have __exp_finite, it

Hello, I see here: https://llvm.org/docs/LangRef.html#ret-instruction That the return instruction must only return values of first class types, which would exclude struct and arrays. But some llvm instrinsics do return struct, and it does not seems to be enforced on any function. Is that restriction lifted and the documentation not up to date? Can we return arrays? I see the same restriction for select. Can/should we lift it too? -- *Alexandre Isoard* -------------- next part -------------- An HTML a...

Dear Friends. I found a puzzling phenomenon in R when you use 'if' within a function: # defining a function aaa aaa=function(a) {if (a==1) {aaa=1}; if (a!=1) {aaa=2} } # using the function: > b=20 > bbb=aaa(b) > bbb [1] 2 > typeof(bbb) [1] "double" > > > c=1 > ccc=aaa(c) > ccc NULL > typeof(ccc) [1] "NULL" It seems that only the last

...ere when you want to use your own implementations. Teresa On Fri, Mar 23, 2018 at 8:39 AM, Bakhvalov, Denis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Dear community, > > > > Recently I discovered that llvm gold linker plugin (LLVMgold.so) doesn't > add llvm instrinsics symbols to the linker symbol table. I do not claim > that something is necessary wrong, just want to share my observations with > the community. > > > > Brief summary > > > > If I create a static library with a custom version of ‘exp()’ math > functio...

...ts.llvm.org > <llvm-dev-bounces at lists.llvm.org>] *On Behalf Of *Craig Topper via > llvm-dev > *Sent:* Wednesday, September 20, 2017 1:01 PM > *To:* Daniel Berlin > *Cc:* llvm-dev > *Subject:* Re: [llvm-dev] RFC: [X86] Can we begin removing AutoUpgrade > support for x86 instrinsics added in early 3.X versions > > Many of the older autoupgrades have no test cases because I think when we > upgraded them we just replace all the code in the tests with native IR. So > for some of the code we don't even know if it works. > > I don't really want to watch th...

We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics that have been replaced with native IR over the years. Has enough time and/or versions passed that we can begin phasing out some of this code? As I'm writing these we don't seem to have tests for a lot of the older upgrades. We've done better at this in the last few years. 3.1 added upgrade for: