similar to: [LLVMdev] Inlining and exception handling in LLVM and GCC

Hi John, >> 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() >>

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

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 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() {

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

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 =

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 Bill, there is clearly a misunderstanding: either I am missing something essential or you are. To clear this up, I suggest you send me evil examples and I will show you how my scheme handles them (or doesn't handle them, if I am indeed failing to see something). > This is the code that G++ generates from the example in my proposal: ... > If the call to __Z3foov throws, we need to

Hi Bill, Thanks for working on this. Is there a reference for the function attribute uwtable, or is it to be defined as part of this effort? Thanks in advance Garrison On Jul 23, 2011, at 1:29, Bill Wendling wrote: > 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

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

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

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

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

Hi Reid, I've been working on the outlining code and have a prototype that produces what I want for a simple case. Now I'm thinking about the heuristics for recognizing the various logical pieces for C++ exception handling code and removing them once they’ve been cloned. I've been working from various comments you've made earlier in this thread, and I'd like to run something

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

I don’t know much about SEH and haven’t had time to really dig into this, but the idea of outlining functions that need to know about the frame layout sounds a bit scary. Is it really necessary? I’m wondering if you can treat the cleanups and filter functions as portions of the same function, instead of outlining them to separate functions. Can you arrange to set up the base pointer on entry to