similar to: [LLVMdev] Are instr_iterators invalidated when function inlining is performed?

Hi, I'm trying to write a small piece of code that inlines all calls to a particular function. The codes is as follows Function* klee_check_divF = module->getFunction("klee_div_zero_check"); assert(klee_check_divF != 0 && "Failed to find klee_div_zero_check function"); // Hack inline checks for (Module::iterator f = module->begin(), fe =

Hi, I'm working on a tool (KLEE) that interprets LLVM bitcode. One of the things it does is it instruments the LLVM bitcode with checks for division by zero. It does this by injecting calls to a function "klee_div_zero_check(long long divisor)" just before every division instruction (e.g. SDiv). These checks are injected by a pass that has been implemented in KLEE. This

Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing,

I've got a call instruction: call void bitcast (void (%4 addrspace(1)*, <2 x i32>, <4 x float>)* @_Z12write_imagefPU3AS110_image2d_tDv2_iDv4_f to void (%9 addrspace(1)*, <2 x i32>, <4 x float>)*)(%9 addrspace(1)* %dstimg, <2 x i32> %28, <4 x float> %26) nounwind %4 and %9 are both (stripped) opaque structs. InlineFunction() does not inline this because

On Fri, Nov 9, 2012 at 3:25 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > I've got a call instruction: > call void bitcast (void (%4 addrspace(1)*, <2 x i32>, <4 x float>)* @_Z12write_imagefPU3AS110_image2d_tDv2_iDv4_f to void (%9 addrspace(1)*, <2 x i32>, <4 x float>)*)(%9 addrspace(1)* %dstimg, <2 x i32> %28, <4 x float> %26)

Hello, I have a CallInstr for "functionA". I renamed it to "functionB" but I want to decrease number of arguments as functionA accepts e.g two and functionB just one. So far, I dont find any function to just replace args / set args size. Any idea? Maybe other solution... Is there any way to create a new CallInstr for functionB, copy things from CallInstr of functionB a copy

Eli, Thanks. I don't think it's a bug in the linker, really… it's required to treat (stripped) opaque types as different, since it really has no way to know if the caller and the callee really are referring to the same thing… though it then seems to turn right around and do exactly that by inserting the bitcast. ;-) (That does come from the linker.) That the linker 'works

On May 26, 2009, at 3:15 PM, Jeffrey Yasskin wrote: > In Unladen Swallow we (intend to) compile each function as we > determine it's hot. To "compile" a function means to translate it from > CPython bytecode to LLVM IR, optimize the IR using a > FunctionPassManager, and JIT the IR to machine code. We'd like to > include inlining among our optimizations. Currently

Is there a way to access the current MachineBasicBlock info from within CodeGenIntrinsic in SparcV9BurgISel.cpp? The arguments are: Intrinsic::ID iid, CallInst &callInstr, TargetMachine &target, and std::vector<MachineInstr*>& mvec, none of which seem to offer access to the current MachineBasicBlock. Brent

Hi John, On Thu, Nov 5, 2009 at 8:43 AM, John Criswell <criswell at uiuc.edu> wrote: > Does the debug facilities in LLVM TOT, at present, maintain information > better than LLVM 2.6 (i.e., if a front-end puts the debug information in, > will the optimizations not take it out)?  Does the information that the > llvm-gcc front-end adds comparable to what llvm-gcc in LLVM 2.6 does?

Hi, I want to convert a function pointer call in the IR of MPlayer to a function call. For example, I have the following line: ... %10 = tail call i32 %7(%struct.demuxer* nonnull %0, i32 %1, i8* %2) #7, !dbg !863222 ... I want to set the target which is stored in %7 to a real function called "demux_lavf_control()" with the following definition: ... define internal i32

Hi, There is a problem with the handling of alwaysinline functions in Clang: they are not always inlined. AFAIK, this may only happen when the caller is in the dead code, but then we don't always successfully remove all dead code. Because of this, we may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function. Libc++ relies on the compiler

I would like to start prototyping changes towards profile guided inlining. Before doing so, I wanted to get feedback from the community on the appropriate approach. I'm going to layout a strawman proposal, but I'm open to other ideas on how to approach the problem. Depending on what approach we settle on, I *may* be able to commit resources to actually implement this in the near

Hello, My idea is to detect a multithreading and perform some transformations and get new possibilities for optimizations: 1. Check pthread_create and follow CallInstr (goal: to know that we are in new thread), identify functions where fork is used and check all other CallIstr (we are in child) + check Windows variants of fork/ thread create.. 2. Check functions if they do not contain any of

On 20 December 2013 05:39, Daniel Liew <daniel.liew at imperial.ac.uk> wrote: > Hi Rafael and other LLVM devs, > > I'm currently upgrading a project that uses LLVM that links a bitcode > archive (a C library) with a module. Originally we used > Linker::LinkInFile() but that was removed by r172749. So I started > looking for an alternative and I found >

On Thu, Aug 20, 2015 at 7:17 PM, John McCall <rjmccall at apple.com> wrote: > > On Aug 20, 2015, at 5:19 PM, Evgenii Stepanov via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > Hi, > > > > There is a problem with the handling of alwaysinline functions in > > Clang: they are not always inlined. AFAIK, this may only happen when > > the caller is

Hi Daniel, Thanks for your answer. > I am considering fixing the bug in the LLVM CommandLine library but is > going to be a long time before I can look at it. So don't wait for me > to do that. > Ok, ok, but, if you end up fixing this, please keep me post. > If you are really desperate to have the command line options in the > way you want they you may need to implement

On 11 February 2016 at 17:08, Reid Kleckner <rnk at google.com> wrote: > On Thu, Feb 11, 2016 at 5:53 AM, Dan Liew via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> >> > Can you somehow verify that this heap-use-after-free is happening? >> > E.g. print all the pointer values coming from memory::allocate, coming >> > into >> >

On Wed, 16 Sep 2020 at 22:24, David Blaikie <dblaikie at gmail.com> wrote: > > I appreciate the value of the feature - but it's possible the test > doesn't pull its weight. Is the code that implements the feature > liable to failure/often touched? If it's pretty static/failure is > unlikely, possibly the time and flaky failures aren't worth the value > of

On Fri, Sep 2, 2011 at 4:23 AM, Mian M. Hamayun <mian-muhammad.hamayun at imag.fr> wrote: > But I am also looking into the possibility of doing the same using LLVM Pass > Manager (Without using llvm-ld). This looks difficult due to the fact that > the function definitions ought to be in the same module as the caller, in > order to be inlined and then optimized onwards, I guess