similar to: [LLVMdev] callinst vs. invokeinst

I'm about to commit my changes to update the InvokeInst constructors to work like CallInst. Untill I get all of the llvm-gcc changes in, there will be a small window where llvm-gcc won't build. This shouldn't take more than 15-20 minutes depending on how fast subversion is. -Dave

While improving ADCE, i notice that for declare i32 @strlen(i8*) readnone define i32 @test() { ; invoke of pure function should not be deleted! invoke i32 @strlen( i8* null ) readnone to label %Cont unwind label %Other ; <i32>:1 [#uses=0] Cont: ; preds = %0 ret i32 0 Other: ; preds = %0 %exn = landingpad {i8*, i32} personality i32 (...)* @__gxx_personality_v0

> Args needs to be an array of the arguments and NumArgs needs to be the > size of the array. If you have a std::vector then you can just: > > new CallInst(F, &ArgVec[0], ArgVec.size(), ...) Doesn't the code above make an assumption about how std::vector is implemented? If ArgVec is defined as std::vector<Value*> ArgVec; then &ArgVec[0] returns a Value**. Let

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,

On Mon, 27 Aug 2007, David Greene wrote: > I'm about to commit my changes to update the InvokeInst constructors to work > like CallInst. Untill I get all of the llvm-gcc changes in, there will be a > small window where llvm-gcc won't build. This shouldn't take more than > 15-20 minutes depending on how fast subversion is. svn has atomic commits: can you commit both at

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

Thanks for the help Reid! I frequently look at the online doxygen, but sometimes its difficult to determine the correct replacement when a method is removed from LLVM. In this particular case, I knew which new CallInst constructor to use, I just couldn't figure out the proper syntax. At any rate, I really appreciate your help!! Reid Spencer wrote: > On Tue, 2007-03-06 at 22:44 -0600,

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

To create a new CallInst I used to call the following constructor: CallInst(Value *F, const std::vector<Value*> &Par, const std::string &Name = "", Instruction *InsertBefore = 0); However, it seems as though that constructor has been removed. I assume that I'm suppossed to use the following constructor, but I can't figure out what to pass as the Args parameter

On Tue, 2007-03-06 at 22:44 -0600, Ryan M. Lefever wrote: > To create a new CallInst I used to call the following constructor: > > CallInst(Value *F, const std::vector<Value*> &Par, const std::string > &Name = "", Instruction *InsertBefore = 0); > > However, it seems as though that constructor has been removed. I assume > that I'm suppossed to

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 >

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

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) { ===> }

songlh at cs.wisc.edu wrote: > Hi everyone: > > The code I am analyzing is : > > int main() > { > int i = 0; > printf("hello world!"); > printf( "%d" , i ); > } > > > > I want to get each place where printf is called, and the argument used > during that call. > > so I write llvm

+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 Sat, Mar 15, 2008 at 7:33 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > 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

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.