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

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 proposal seems strangely complicated. I don't see the advantage of the dispatch instruction over just attaching the information to each invoke. Right now you have invoke void @_Z3foov() to label %invcont unwind label %catch.handlers catch.handlers: landingpad dispatch resume to label %... catches [ %struct.__fundamental_type_info_pseudo* @_ZTIi, label

On Dec 1, 2010, at 10:20 AM, Duncan Sands wrote: > Hi Bill, this proposal seems strangely complicated. I don't see the advantage > of the dispatch instruction over just attaching the information to each invoke. > Right now you have > > invoke void @_Z3foov() > to label %invcont unwind label %catch.handlers > > catch.handlers: landingpad > dispatch resume

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

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

Hi everyone! I've been silently working on the previous exception handling proposal I published last year (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-November/027311.html). However, there were some major deficiencies in it. After discussing this further with Jim Grosbach and John McCall, we've come up with another proposal. As you can see, it incorporates the idea of

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 Duncan, >>are you trying to get the name "@_ZTIi" or "@__cxa_throw"? yes! i want get the name @_ZTi or @__cxa_throw, the latter @__cxa_throw i can get it throw value->getName(), but the @_ZTi it did n't has name! zhangzw thanks 2009/3/26 Duncan Sands <baldrick at free.fr>: > Hi zhangzw, > >> invoke void @__cxa_throw(i8* %7, i8*

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 all, here is a llvm IR : invoke void @__cxa_throw(i8* %7, i8* bitcast (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* null) noreturn to label %invcont unwind label %lpad say I want to get the Invoke's Operand's name, I use getOperand(i)->getName(), it can work for that the Operand hasname, but some Operand hasn't name, So, My problem is how

Hi zhangzw, >> invoke void @__cxa_throw(i8* %7, i8* bitcast >> (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* >> null) >> noreturn to label %invcont unwind label %lpad > > >>are you trying to get the name "@_ZTIi" or "@__cxa_throw"? > > yes! i want get the name @_ZTi or @__cxa_throw, > the latter

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

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

Hi Bill, >> Why not combine this into: >> >> invoke void @_Z3foov() >> to label %invcont unwind resume to label %... >> catches [ >> %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int >> %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %ch.str >> ] >> catchall [i8* null, label % ch.ca <http://ch.ca>] >> >> ?

here are the cpp file: $ cat -n eh1.catch.cpp 1 #include <iostream> 2 3 int main() 4 { 5 try { 6 throw 78; 7 } 8 catch (int){ 9 10 std::cout << "at catch\n"; 11 12 } 13 } LLVM-IR: $ llvm-g++ -S -emit-llvm eh1.catch.cpp -o eh1.catch.ll ... 46 define i32 @main() {

Hi zhangzw, > invoke void @__cxa_throw(i8* %7, i8* bitcast > (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* > null) > noreturn to label %invcont unwind label %lpad > > say I want to get the Invoke's Operand's name are you trying to get the name "@_ZTIi" or "@__cxa_throw"? Ciao, Duncan.

(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