similar to: Finding callees of a function

Hi, I have a llvm-pass in hand written by other people. There are following statements that I couldn't understand: -------------------------------program---------------------------------------------------- ... if (isa<CallInst>(inst) || isa<InvokeInst>(inst)) { const CallSite cs(inst); if (cs.getCalledFunction() == NULL) return dealAtIndirectCall(cs); else

Hello, In my module I have functions: a b c f3 calls "a" f2 calls "a" f1 calls "b" I would like to modify a CallInst in the f2. Now it calls "a", but I want changed it to "c". When loop over the instructions of the f2, I can get a CallInst to be modified, then I use "setName" to changed it to "c". Problem is, since

I was wondering if someone could explain why CallInst::getCalledFunc behaves the way it does. For simple, direct call instructions in my IR, that method behaves just as one would expect. However, for instructions like this: %25 = call i32 (%struct._IO_FILE*, ...)* bitcast (i32 (...)* @close to i32 > (%struct._IO_FILE*, ...)*)(%struct._IO_FILE* %24), !dbg !695 getCalledFunc returns null. I

On Nov 29, 2010, at 5:22 PM, huwei8717 wrote: > Hi, > > I have a llvm-pass in hand written by other people. There are following statements that I couldn't understand: > > -------------------------------program---------------------------------------------------- > ... > if (isa<CallInst>(inst) || isa<InvokeInst>(inst)) { > const CallSite cs(inst);

You are probably calling setName() on the called Function, which in-turned renamed the called Function instead of replacing the called function. Depending on your use-case, if you are certain that you only need to modify CallInsts, then you could simply call CallInst::setCalledFunction , otherwise it’s probably wiser to use CallSite as a wrapper for both CallInst and InvokeInst. Do note, however,

Going to keep this RFC short and to the point: TerminatorInst doesn't pull its weight in the type system. There is essentially a single relevant API -- iterating successors. There is no other interesting aspect shared -- the interface itself just dispatches to specific instructions to be implemented. On the flip side, CallInst and InvokeInst have *massive* amounts of code shared and struggle

On Thu, May 17, 2018 at 10:32 AM Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Going to keep this RFC short and to the point: >> >> TerminatorInst doesn't pull its weight in the type system. There is >> essentially a single

On Thu, May 17, 2018 at 1:24 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > On Thu, May 17, 2018 at 10:32 AM Xinliang David Li <xinliangli at gmail.com> > wrote: > >> >> >> On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Going to keep this RFC short and to the

On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is > essentially a single relevant API -- iterating successors. There is no > other interesting aspect shared -- the interface itself just dispatches to

> On May 17, 2018, at 2:03 AM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is essentially a single relevant API -- iterating successors. There is no other interesting aspect shared -- the interface itself just dispatches to

+1, sounds like a great idea And if you're volunteering to do the work, even better! :) Philip p.s. Any reason we can't preserve a TerminatorInst type with an isa function which just returns true for all our terminators but without having terminators actually inherit from it?  If so, we preserve the bit of a "type safety" for a variable which is expected to always point to

Are there any instructions that aren't terminators now, but will become terminators with this change? I'm wondering if this is going to affect reading old bitcode, and if so, how it will be handled. -Krzysztof On 5/17/2018 4:03 AM, Chandler Carruth via llvm-dev wrote: > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type

On Fri, May 18, 2018 at 10:26 PM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > On May 17, 2018, at 2:03 AM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Going to keep this RFC short and to the point: > > > > TerminatorInst doesn't pull its weight in the type system. There is >

Erick, After some experimentation, I'd prefer the closed system. LLVM has some type peculiarities like the commonality between CallInst and InvokeInst. I find that the closed type system lets me express such constraints more naturally. Expressing these constraints explicitly in the open system involves annotating the C++ class hierarchy with extra variants which are unnecessary in

On 05/17/2018 04:03 AM, Chandler Carruth via llvm-dev wrote: > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is > essentially a single relevant API -- iterating successors. There is no > other interesting aspect shared -- the interface itself just > dispatches to specific instructions to be implemented.

Hi all, Sorry for the inconvenient about the previous post. The files were not attached. So I put them here again. I am a newbie in LLVM and I am trying to replace the function like: old function || new function ============================== ========= int haha(int a) { int haha(int a, char* ID) { ===> }

Hi R friends,   I'm still studying S4 classes and I have a question about slot assignment. Why would I have to use a special setter method [example 2 below] if I can assign data to a slot directly when I call new() [example 1 below]?   ## first way to do it (the idiosyncratic way?) setClass(Class = "TestClass", representation = representation(myDf = "data.frame"))

Hello,   I am trying to write some code that dumps R objects to the harddisk in a binary format so they can be quickly re-used later. Goal is to save time. The objects may be quite large (e.g. classes for a GUI). I was thinking that save() and load() would be suitable for this (until now I only thought it could be used for 'real' data, e.g. matrices, data.frames etc), but I am hoping any

I'm now writing a pass and I wanna ask a question about how to duplicate the function and add duplicated arguments in llvm, for example: func(int a, char *b) -> func(int a, char *b, int a1, char *b1) I'm now stuck at using "getOrInsertFunction" and how to handle "getArgumentList", please share your opinion, thanks a lot! James

Hi, Artur > The interesting for me part of the CallInst is printf(i8* noalias %0, i32 > 123). > I was diging in doxygen documentation but I really can't see the easy way to > compare those instructions and again finish with reinvented (but working) > wheel ;). Ah, sorry. I missed that you're doing variadic calls, not casting variadic function to definite ones. I think you