search for: invokeinst

What is the difference between a CallInst and an InvokeInst in LLVM? Is an InvokeInst a CallInst that can throw an exception? Thanks, Ryan

...re i32 @__gxx_personality_v0(...) Instruction:: mayThrow returns false for the invoke. This is because ... bool Instruction::mayThrow() const { if (const CallInst *CI = dyn_cast<CallInst>(this)) return !CI->doesNotThrow(); return isa<ResumeInst>(this); } CallInst != InvokeInst, and invokeinst is not derived from callinst. Am I missing something, or should this function also have: if (const InvokeInst *II = dyn_cast<InvokeInst>(this)) return !II->doesNotThrow(); ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://list...

...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 to be effective due to being unable to share a base >> class in the type system. We have CallSite and a host of other complexity >> trying to cope with this, and honestly, it isn't doing such a great job. >> >>...

...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 to be effective due to being unable to share a base class in the type system. We have CallSite and a host of other complexity trying to cope with this, and honestly, it isn't doing such a great job. I propose we make "terminator-ness&quot...

...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 to be effective due to being unable to share a base >>> class in the type system. We have CallSite and a host of other complexity >>> trying to cope with this, and honestly, it isn't doing such a great job. >&g...

Is it okay to pass null values to the destinations of InvokeInst::Create? I checked the code and it looks like it'd be okay, but the Create method doesn't make them optional, so I'm uncertain. Perhaps a specific Create function without destinations can be added to make it clear that it's okay (of course assuming you eventually call setNormal/Unwi...

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

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 the sam...

...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 to be effective due to being unable to share a base > class in the type system. We have CallSite and a host of other complexity > trying to cope with this, and honestly, it isn't doing such a great job. > > I propose we make &q...

...erminatorInst 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 to be effective due to being unable to share a base class in the type system. We have CallSite and a host of other complexity trying to cope with this, and honestly, it isn't doing such a great job. > > I propose we make "terminator...

On Monday 27 August 2007 13:17, Chris Lattner wrote: > 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 yo...

...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 to be effective due to being unable to share a base > class in the type system. We have CallSite and a host of other complexity > trying to cope with this, and honestly, it isn't doing such a great job. > > > > I propose...

..._back(*AI); } // Then, insert the new argument Args.push_back(CallerGlobals); // Lastly, copy any remaining varargs for (; AI != AE; ++AI) { Args.push_back(*AI); } Instruction *New; Instruction *Before = Call; if ( InvokeInst *II = dyn_cast<InvokeInst>(Call) ) { New = InvokeInst::Create(NF, II->getNormalDest(), II->getUnwindDest(), Args, "", Before); cast<InvokeInst>(New)->setCallingConv(CS.getCallingConv()); // cast<InvokeInst>(New)->setParamAttrs...

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 the closed model. Please use 'a Llvm.ty for Type and ...

...sn'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 to be effective due to being unable to share > a base class in the type system. We have CallSite and a host of other > complexity trying to cope with this, and honestly, it isn't doing such > a great job. > > I propose w...

...n'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 to be effective due to being unable to share a base > class in the type system. We have CallSite and a host of other > complexity trying to cope with this, and honestly, it isn't doing such a > great job. > > I propose...

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 system involves > annotating the C++ class hierarchy with extra variants which are unnecessary > in the closed model. It looks like you might be...

...n type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token type would help us to avoid this. I have most of the code work but got a problem when gc.statepint is an InvokeInst and has an unwind path. Currently, gc.statepoint of InvokeInst works as below (the code snippet is from test/CodeGen/X86/statepoint-invoke.ll): %0 = invoke i32 (i64, i32, void (i64 addrspace(1)*)*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_isVoidp1i64f(i64 0, i32 0, void (i64 addrspac...

...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 to be effective due to being unable to share > a base class in the type system. We have CallSite and a host of other > complexity trying to cope with this, and honestly, it isn't doing such > a great job. > > I propose we ma...

...llvm pass code like: void Myfunction( Function & F){ for( Function::iterator b = F.begin() , be = F.end() ; b != be; ++b){ for(BasicBlock::iterator i = b.begin() , ie = b.end(); i != ie; i ++){ if( isa<CallInst>(&(*i)) || isa<InvokeInst>(&(*i))){ //how could I get the function name and argument //used here } } } } How could I get the function name and the arguments when I know an Instruction is a function call? thanks a lot! Best wishes!...