similar to: [LLVMdev] invoke semantics

> Teach IndVarSimplify's FixUsesBeforeDefs to handle InvokeInsts by > assuming that the use of the value is in a block dominated by the > "normal" destination. More precisely, the use has to be dominated by the *edge* from the invoke to its normal destination. This could certainly do with being documented properly. Jay.

On May 22, 2009, at 12:02 PM, Jay Foad wrote: >> It'd be good for someone actually familiar with invoke could comment >> >> on this. Specifically, in the following testcase, the return value of >> >> the invoke is used in the unwind destination, which is not reachable >> >> from the normal destination. Should this be valid? >> > > No. If

> It'd be good for someone actually familiar with invoke could comment > on this. Specifically, in the following testcase, the return value of > the invoke is used in the unwind destination, which is not reachable > from the normal destination. Should this be valid? No. If the invoked function unwinds then it doesn't return a value. I'm pretty sure that -verify will reject

>> No. If the invoked function unwinds then it doesn't return a value. >> I'm pretty sure that -verify will reject your testcase. > > Thanks to you and others for answering this. I've added a sentence to > LangRef.html making this explicit. I've had a go at documenting a bit more rigorously how phi and invoke instructions affect the SSA form. Patch attached.

Hi Dale, > #include <cstdio> > class A { > public: > A() {} > ~A() {} > }; > void f() { > A a; > throw 5.0; > } > main() { > try { > f(); > } catch(...) { printf("caught\n"); } > } this example indeed shows the problem. Let me explain to see if we agree on what the problem is. Suppose we don't artificially

Hi Dale, > No, I don't want to change the semantics of invoke, at least I don't > think so. > When inlining, I want the inlined throw to reach cleanup code as it > does. > But I want the Unwind_Resume call that ends the cleanup code to be > replaced with a control transfer to the handler (or cleanup) in the > calling > function, i.e. the inliner needs to know

Hi, I wanted to propose an IR extension that would allow us to support zero-cost exception handling for non-call operations that may trap. I wanted to start with loads and stores through a null pointer, and later we might extend this to div/rem/mod zero. This feature is obviously useful for implementing languages such as Java and Go which deterministically translate such operations into

I like the idea of the landing pad being associated with the basic block. It seems to me that the branch to the landing pad should be viewed as occurring at the beginning of the "earliest" block to branch to that landing pad. No assignments that occur in any block that unwinds to a particular landing pad are valid in that landing pad or any subsequent blocks. Other than that, standard

Here is an alternative proposal to Bill's. It is closer to what we already have (which can be seen as a good or a bad thing!), and is also closer to what gcc does. It is more incremental than Bill's and introduces fewer new concepts. Executive summary ----------------- Remove the personality and list of catches out of eh.selector and stick them directly on invoke instructions. The

I've been looking into a new way to implement exception handling in LLVM. The current model has many disadvantages, in my opinion. I try to address them with this proposal. I also try to make exception handling much more understandable to the normal human reader. :-) Any new proposal will need to address all present and future languages' exception handling methodologies. I

On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote: > Executive summary > ----------------- > > Remove the personality and list of catches out of eh.selector and stick them > directly on invoke instructions. > > The invoke instruction > ---------------------- > > The invoke instruction is modified by adding extra catch info to it: > > <result> = invoke

Hi Jay, > Are you saying that, in the LLVM IR, it would be legal to have an > llvm.eh.exception that *isn't* dominated by convokes (because there's > a direct branch to that catch block), and in that case the call > returns an undefined value? this is already the case (with invoke substituted for convoke). And it would be up to codegen to "peel it > out into its own

On 30 March 2011 19:08, Talin <viridia at gmail.com> wrote: > llvm.gc.declare(alloca, meta). This intrinsic marks an alloca as a garbage > collection root. It can occur anywhere within a function, and lasts either > until the end of the function, or a until matching call to > llvm.gc.undeclare(). > llvm.gc.undeclare(alloca). This intrinsic unmarks and alloca, so that it is

On Mar 23, 2012, at 4:46 PM, Bill Wendling wrote: > You need to look at how the equivalent code in C++ looks in LLVM IR. The "do something with x & y" part will be an 'invoke' that lands on at landing pad, where you will then call the d'tor to your allocated object. OK, after a lot of tinkering (and looking at the ExceptionDemo.cpp file), I have something that works

On Dec 9, 2007, at 1:01 PM, Duncan Sands wrote: > Hi Dale, > >> #include <cstdio> >> class A { >> public: >> A() {} >> ~A() {} >> }; >> void f() { >> A a; >> throw 5.0; >> } >> main() { >> try { >> f(); >> } catch(...) { printf("caught\n"); } >> } > > this example

On 1 December 2010 09:46, Bill Wendling <wendling at apple.com> wrote: > Nor these. Basically, I want the basic block that's labeled a "landing pad" to be jumped to by only a dispatch resume or unwind edge of invoke. We could do this with the c.dtor and ch.int here, but it would mean inserting useless "cleanup dispatches" that only resume to the block (see

On 1 December 2010 11:11, Frits van Bommel <fvbommel at gmail.com> wrote: > Those are destructor calls for the case where none of the foo()s > throw. There are no ctor calls because the classes have trivial > constructors, which are no-ops. Indeed! Thanks! ;) > If there were also catches, they'd probably need to explicitly execute > the finally code (or if they again

Hi, It looks like PDT.getRootNode() returns NULL for: define fastcc void @c974001__lengthy_calculation. 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { entry: br label %bb bb: br label %bb } Isn't it a bug in PostDominatorTree? Please note that this crashes: opt -postdomtree -debug dom_crash.bc I think this should be reported as a bug, -Jakub On Sep 3, 2009, at

Jakub Staszak wrote: > Hi, > > It looks like PDT.getRootNode() returns NULL for: > > define fastcc void @c974001__lengthy_calculation. > 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { > entry: > br label %bb > > bb: > br label %bb > } > > > Isn't it a bug in PostDominatorTree? > > Please note that this crashes: >

On Dec 1, 2010, at 2:37 AM, Renato Golin wrote: > On 1 December 2010 09:46, Bill Wendling <wendling at apple.com> wrote: >> Nor these. Basically, I want the basic block that's labeled a "landing pad" to be jumped to by only a dispatch resume or unwind edge of invoke. We could do this with the c.dtor and ch.int here, but it would mean inserting useless "cleanup