similar to: [LLVMdev] Nested exception handlers

Hi Talin, > Since llvm-gcc is a rather large code base, which I have never looked at > (or even run), could you give me a starting point of where to look? I meant: compile some nested C++ with llvm-gcc to see what it does. Otherwise, look in llvm-convert.cpp, especially EmitLandingPads. > One thing I'd be interested in knowing is whether the > llvm.eh.exception() intrinsic can

Since llvm-gcc is a rather large code base, which I have never looked at (or even run), could you give me a starting point of where to look? One thing I'd be interested in knowing is whether the llvm.eh.exception() intrinsic can be called more than once in a landing pad. Say for example I have a nested try block, so that there are two landing pads, one for the inner try block, and one for

Hi Talin, > Now that I've got exceptions working, I'm kind of wondering how to > handle the case of nested "try" blocks. Say I have some code that looks > like this: take a look at what llvm-gcc does for this kind of thing. Ciao, Duncan.

I was thinking about this last night, and I came up with a third alternative which I think looks very promising. It’s basically a re-working of the previous alternative to use the landingpad concept rather than arbitrary fake logic, but it uses a single landing pad for the entire function that mimics the logic of the personality function to dispatch unwinding calls and catch handlers. I believe

I am working on adding support for C++ exception handling when compiling for a native Windows target (that is a target with "MSVC" specified as the environment). Because of differences between how the native Windows runtime handles exceptions and the Itanium-based model used by current LLVM exception handling code, I believe this will require some extensions to the LLVM IR, though

Hi Reid, Thanks for the input. You wrote: > The @_Z4testv.unwind.1 helper just calls ~Inner(), but not ~Outer. That’s actually intentional. The thing to keep in mind is that all of the landing pads are going to be effectively removed by the time the final object image is generated. They are just there to facilitate the table generation, and in the __CxxFrameHandler3 case they don’t mean

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

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 Bill, > This is similar to my first proposal. yup, I still consider your first proposal to have been basically sound. But it also suffers from a major problem, > which stopped that proposal dead in its tracks. Namely, you have information in > one place which needs to be shared in two different, but possibly disjoint, > places: the type, filters, and personality information. In

Bill, I believe the empty-exception-specification example is a red- herring, but that if you can construct an example where you think a landing-pad requires multiple filter lists then I think we can then have a productive conversation about it. I believe we can only get multiple filter lists in a landing-pad if we attempt to merge exception-regions, and since filters are only an

This is a revision of the second exception handling proposal I sent out. You can see it here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036484.html After much discussion, there are some changes to the proposal – some significant and some minor. One major point, this proposal does not address the issue of catching an exception thrown from a non-invoke instruction. However if done

Thanks, Reid. These are good points. So I guess that does take us back to something more like my original proposal. I like your suggestion of having some kind of “eh.actions” intrinsic to represent the outlining rather than the extension to landingpad that I had proposed. I was just working on something like that in conjunction with my second alternative idea. What I’d really like is to have

Hi Garrison, > I hacked together a version of DwarfEHPrepare.cpp which tries to deal with the ordering of llvm.eh.exception and llvm.eh.selector. > The hacked is contained within the attached patch. it looks like you tried to copy the code for eh.exception. There are two problems with this: (1) the eh.exception code really needs to be rewritten to make use of the new SSAUpdator (then all

Hi Shivram, > I'm trying to compile an llvm program which makes use of exception > handling. While compiling the code with llc i get the following > assertion failure an unfortunate weakness of the code generators is that they require calls to eh.selector to be in a landing pad (landing pad = where an invoke unwinds to). They can also handle some simple cases when the selector call

Hi, I'm trying to compile an llvm program which makes use of exception handling. While compiling the code with llc i get the following assertion failure llc: FunctionLoweringInfo.cpp:163: void llvm::FunctionLoweringInfo::clear(): Assertion `CatchInfoFound.size() == CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"' failed. 0 llc

On Aug 4, 2011, at 4:03 PM, Peter Lawrence wrote: > Bill, > I believe the empty-exception-specification example is a red-herring, > but that if you can construct an example where you think a landing-pad > requires multiple filter lists then I think we can then have a productive > conversation about it. > > I believe we can only get multiple filter lists in a

Bill, ooops, yes, I described the meaning of "throw(A)" backwards, but I still think my example shows why you cannot merge LandingpadInst while inlining because multiple filter-lists on a LandingpadInst don't make sense. Perhaps I'm reading your original spec wrong, perhaps I'm mis-reading Duncan's emails, but I read them to mean that your syntax supports

On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote: > Inlining > -------- > > Many a plausible seeming exception handling scheme has fallen by the way-side > because it interacts poorly with inlining. > > Here is how inlining would work with this scheme. It's pretty close to how > it works right now. Suppose you have > > invoke void @foo() > to

Hi Duncan, I hacked together a version of DwarfEHPrepare.cpp which tries to deal with the ordering of llvm.eh.exception and llvm.eh.selector. The hacked is contained within the attached patch. Motivation: I recently created a decent amount of hand coded IR (via the llvm C++ API). In order to help me runtime debug the code, I created automatic constructors which would trace entries into the

I've read and re-read the LLVM exception handling doc, and there are a number of things that aren't clear to me. In the section describing llvm.eh.exception, it says "The backend replaces this intrinsic with the code that accesses the first argument of a call." I don't understand this sentence. A call to what? What is meant by 'accesses' - do you mean