similar to: [LLVMdev] Interprocedural use-def chains

Thanks for your reply. Yes, I was about to recurse over the use list of the argument in the called function. I did not want to pursue that because with this solution, I am going to implement the interprocedural part myself and was wondering if that was not already done. I was not also 100% sure that this will work for any type of arguments. If, based on your response, this is my only solution

On Tue, Jul 26, 2016 at 3:05 PM Dounia Khaldi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for your reply. > > Yes, I was about to recurse over the use list of the argument in the > called function. I did not want to pursue that because with this solution, > I am going to implement the interprocedural part myself and was wondering > if that was not already

Hello, In one of the loop transformations I am developing, I need to convert eq and neq loop latch condition into less than or greater than depending on the control flow. The problem is that CmpInst::ICMP_EQ and CmpInst::ICMP_NE are neither signed nor unsigned in LLVM. Also, I did not find a way to find out if the integer operands of the CmpInst are signed or unsigned. Apparently, LLVM does

Thanks Arpith for this pointer but it did not contain what I was looking for. However, I solved my issue by finding that the BitCastInst used when outlining OpenMP parallel region offers a method for retrieving the original value within the bitcast via stripPointerCasts(). So what I did to retrieve omp_outlined..45 is: //bitcast is the third argument of __kmpc_fork_call Value *vcall =

I'm part of a research group at MIT looking to create an extension of LLVM that inherently allows one to nicely code a parallel loop. Most parallel frameworks tend to take the body of a parallel loop and stick it inside of a function for the parallel runtime to call when appropriate. However, this makes optimizations significantly more difficult as most compiler optimizations tend to be

Dear community, In preparation for the BoF on Parallel IR at the US developers meeting we would like to collect feedback from the whole community. The concerns, ideas, etc. will be summarized in the BoF and should provide a good starting point for a discussion. We know that over the years the topic of a parallel extension for LLVM was discussed on the mailing list [0, 1, 2], workshops [3, 4] or

Hi Everyone, I asked a question on the dev list related to the topic to which John Criswell and Jeremy Lakeman kindly provided some valuable insight. I'm still stuck on the issue and i'm hoping i didn't phrase the question well enough. I have a *foo.c* file that is : *#include <stdio.h>* *int foo(int a, int b){* * return a+b;* *}* *int main() {* *int x=foo(3,1); *

Hello, I was implementing the llvm_any_type in my intrinsic def int_csa_xxx : Intrinsic<[llvm_any_ty], [llvm_i32_ty]>; as the following in its corresponding builtins in Builtins.def: BUILTIN(__builtin_xxx, "v.", "nt") the "t" was sufficient here to not perform any type checking. The type checking was handled in CGBuiltin.cpp. This was working until

At least one proprietary linker put a lot of effort into deduplicating and rewriting debug information. This took up the majority of the link time despite serious engineering time on performance optimisation. For example, some sections were written from scratch by the linker because that proved faster than parsing the input. Teaching LLD to dedup DWARF should be expected to dramatically slow it

Hello, The third argument of the OpenMP runtime call __kmpc_fork_call is the outlined function resulting from omp parallel directive; this is of type kmpc_micro. I can get this argument as an LLVM value by using (callInst->getArgOperand...), but once I get this value, i am stuck in knowing its class type. An example of this value can be: void (i32*, i32*, ...)* bitcast (void (i32*, i32*,

Sanjoy, Joseph, and I will be hosting a BoF on using LLVM to build compilers for managed languages. We're curious to hear who's planning on attending and what topics you'd like to hear about. Depending on the expected audience, we're happy to do anything between a rough "what to expect getting started" to a down in the weeds working session on relevant optimization

Hi, 1. I think you should apply the attached patch to openssh-2.9p1, otherwise ssh-keyscan on linux boxes with glibc-2.1 will experience enormous timeout delays. 2. Is there a program like ssh-keyscan for the Version2 (dsa and rsa) keys?? regards Peter Breitenlohner <peb at mppmu.mpg.de> -------------- next part -------------- diff -ur openssh-2.9p1.orig/ssh-keyscan.c

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

In IntrinsicEmitter::EmitTypeGenerate, called from IntrinsicEmitter::EmitGenerator, here for (unsigned j = 0; j != N; ++j) { OS << " ArgTys.push_back("; EmitTypeGenerate(OS, ParamTys[j], ArgNo); OS << ");\n"; } I'm hitting this assertion: if (ArgType->isSubClassOf("LLVMMatchType")) { unsigned Number =

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

That's a bug. I'm working on a fix.... On Apr 15, 2009, at 10:16 AM, Villmow, Micah wrote: > In IntrinsicEmitter::EmitTypeGenerate, called from > IntrinsicEmitter::EmitGenerator, here > for (unsigned j = 0; j != N; ++j) { > OS << " ArgTys.push_back("; > EmitTypeGenerate(OS, ParamTys[j], ArgNo); > OS << ");\n"; > }

On Sep 28, 2007, at 11:36 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > I moved my code to 2.1 but still the same. > If I make ADD i16 legal, then it goes through, but it has problem > expanding it to i8. > Should I go ahead and customize it and do the same for all > instructions? > Or there is a more general thing that I

I have this intrinsic definition for llvm. def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty], [llvm_anyfloat_ty, LLVMMatchType<0>]>; Can someone explain what LLVMMatchType does and how to specify it to match the first argument and not the return value? I've tried LLVMMatchType<1> but it fails in IntrinsicEmitter.cpp

On Apr 15, 2009, at 9:29 AM, Villmow, Micah wrote: > I have this intrinsic definition for llvm. > def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty], > [llvm_anyfloat_ty, LLVMMatchType<0>]>; > > > Can someone explain what LLVMMatchType does and how to specify it > to match the first argument and not the return value?

I moved my code to 2.1 but still the same. If I make ADD i16 legal, then it goes through, but it has problem expanding it to i8. Should I go ahead and customize it and do the same for all instructions? Or there is a more general thing that I can do? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: