similar to: [LLVMdev] LLVMdev Digest, Vol 85, Issue 50

On Jul 27, 2011, at 10:27 AM, Peter Lawrence wrote: > 1) it is good to see that the "exception regions" idea has been abandoned, it is mathematically > inconsistent with modern optimization theory, and at best would require extra passes to translate > into/outof that representation form. > Yeah. I didn't want to obscure the main proposal by inappropriate nomenclature.

On Jul 27, 2011, at 10:27 AM, Peter Lawrence wrote: > 3.b) I have been thinking about other possible control-flow-graph invariants of the > landingpad blocks and the catch blocks that they lead to, but so far have not come up > with very muchl, I wonder if anyone else is thinking about this...?... > > for example cleanups come before __cxa_begin_catch, but it isn't clear what

What? Yet another EH proposal?! This one is different from the others in that I'm planning to start implementing this shortly. But I want your feedback! I've all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others. Now is your turn! Please read this proposal and send me your comments, suggestions, and concerns. -bw

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

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

After a long tale of sorrow and woe, my colleagues and I stand here before you defeated. The Itanium EH representation is not amenable to implementing MSVC-compatible exceptions. We need a new representation that preserves information about how try-catch blocks are nested. WinEH background ------------------------------- Skip this if you already know a lot about Windows exceptions. On Windows,

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

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

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 Christian, Andy's already covered the major points, but you could consider filing a bug at http://llvm.org/bugs too, especially if you've got a small test-case that demonstrates the issue. Exception handling hasn't been a priority in the past, but as more people adopt LLVM's JIT APIs I suspect it will get more attention, and bug reports will help us figure out what needs doing.

Hi all, Following John's, Duncan's and Bill's proposals about exception handling, I thought I'd summarise what has been discussed so far. ** The problems we're trying to solve are: P1. Different languages have different EH concepts and IR needs to be agnostic (as possible) about that P2. Inlining and optimisations (currently) destroy the EH semantics and produce code that

Hi Christian, > I don’t see anything in the Itanium ABI that says I need to call the function that throws an exception with “invoke” to get exception handling to work! AFAICT, it is the design of LLVM IR and its implementation. To catch the exceptions thrown by the callee functions, we should use the invoke instruction along with the landingpad instruction. If you are calling a function

Hi, I’m looking for advice on how to debug a problem with my exception handling code. I’m asking a specific question here - but general advice on how to debug something like this would be greatly appreciated. Is there any way to get a list of landing pad clauses that are active at a particular point in a program? I'd like to get something like a backtrace but listing all active landing pad

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

Just as an off-the-cuff idea that I haven’t thought through at all, what would you think of the possibility of replacing this: %12 = call i32 @llvm.eh.typeid.for(i8* bitcast (%eh.CatchHandlerType* @llvm.eh.handlertype.H.0 to i8*)) %matches7 = icmp eq i32 %sel6, %12 with this: %matches7 = call i32 @llvm.eh.cmp.selector(i32 %sel6, i8* bitcast (%eh.CatchHandlerType* @llvm.eh.handlertype.H.0

Hi Christian, Thanks for your explanation. I know your situation now. I would suggest you to check the optimization pass used by the JIT compiler, especially IPO/PruneEH.cpp. It will try to add nounwind attribute to functions which will result in the problem you have mentioned earlier. Alternatively, as a workaround, try to add uwtable (function attribute) to the functions that are generated

Hi Bill, there are a couple of things I didn't understand about your proposal, for example how it interacts with inlining, whether it is feasible to do the "turn invoke-of-Unwind_Resume into a branch" optimization and also whether in "resumedest" you still plan to use _Unwind_Resume to continue unwinding up the stack. Could you please show what the LLVM IR would look like

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

Hi Bill, Thanks for the response, I just have a couple more questions. On 11 February 2013 06:45, Bill Wendling <wendling at apple.com> wrote: > As far as which OS/architectures support zero-cost EH and which > support SJLJ, LLVM is designed to assume that Intel supports zero-cost > exceptions and ARM supports SjLj exceptions. However, it's all in the > personality function

Logan, I need to make a correction of the post that preceded this one! I was wrong when I said this: > When I load the bitcode file for this module and then dump it just before it is JITted, the “uwtable” attribute has disappeared - is this prune-eh doing its work even though it’s not listed above in the list of function pass managers? The “uwtable” attribute does not disappear! I had