similar to: [LLVMdev] RFC: New Exception Handling Proposal

I have a couple of questions/concerns. The main one has to do with the opacity of exception types - in other words, will it still be true that the exception types are opaque identifiers, and are only interpreted by the personality function? Since my object representations are not C++-like, I am not using any of the cxa_* C++ library functions. Instead, my code calls the _Unwind functions

> Please read and let me know your opinions! This definitely seems like an improvement on the current situation. >            .---------. >            | convoke | >            `---------' >                 | >                 v >     .-----------------------. >     |                       | >     v                       | >  %normal  

On Nov 20, 2009, at 2:15 AM, Jay Foad wrote: >> Please read and let me know your opinions! > > This definitely seems like an improvement on the current situation. > >> .---------. >> | convoke | >> `---------' >> | >> v >> .-----------------------. >> |

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

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

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

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

On Dec 10, 2007, at 11:38 AM, Duncan Sands wrote: >>> ... If you force a "cleanup" by changing the selector call to: >>> %eh_select8.i = tail call i32 (i8*, i8*, ...)* >>> @llvm.eh.selector.i32( i8* %eh_ptr.i, i8* bitcast (i32 (...)* >>> @__gxx_personality_v0 to i8*), i32 0) >>> then it doesn't work either: the unwinder observes that

Hi, catch_all.cpp: 1 int main() 2 { 3 try { 4 throw 34; 5 } 6 catch (...) {} 7 } llvm-gcc -O3 -S -emit-llvm catch_all.cpp -o catch_all.ll: 1 ; ModuleID = 'catch_all.cpp' 2 target datalayout =

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

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

Nicolas Geoffray wrote: > Hi Talin, > > You're not using the llvm intrinsics for exception handling, so your > code won't work. Using _Unwind_RaiseException should be OK, but your > main function must at least use llvm.eh.exception, > llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. > Let me ask a follow-up question then - if the

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

(Mail system seems to have eaten this, sorry if it's a repeat) On Dec 8, 2007, at 12:48 AM, Duncan Sands wrote: > Hi Dale, > >> - Why was C++ claiming that every selector has a catch-all handler? > > this is easy: because the semantics of invoke require it. Yes, > really. > If unwinding reaches an invoke then control is required to jump to the > unwind basic

Talin wrote: > Nicolas Geoffray wrote: >> Hi Talin, >> >> You're not using the llvm intrinsics for exception handling, so your >> code won't work. Using _Unwind_RaiseException should be OK, but your >> main function must at least use llvm.eh.exception, >> llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. >> >

On Dec 2, 2010, at 2:21 AM, Duncan Sands wrote: > 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

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