search for: maybe_throw

...39;d have to hoist a + b to somewhere that dominates L1 and L2. I think the only BB in your program that dominates is the entry block I don't follow. What path do you see from entry to either L1 or L2 that doesn't pass through the indirectbr? In order to reach either L1 or L2, the call to maybe_throw() must raise an exception (else we'd return 0 from foo), the exception must be caught by one of the two handlers (else we'd unwind out of foo), and one of the outlined handlers must have executed and returned. Don't those conditions correspond to the path from entry to the indirectbr?...

...ectbr, but that needs to work anyway. After looking more closely at the IR, we would probably hoist into the landingpad instead of into the entry block. Here's the IR I have in my head after optimization and hoisting but before outlining: define i32 @foo(i32 %a, i32 %b) { entry: invoke void @maybe_throw() to label %ret unwind label %lpad ret: ret i32 0 ; The return case lpad: %ehvals = landingpad { i8*, i32 } personality ... catch ... ; typeinfo for int catch ... ; typeinfo for float %sum = add i32 %a, %b ; hoisted out from catch_int and catch_float via CSE or something...

...le, perform the add before invoking either handler); is that more or less the idea? That makes sense, thanks. I have the same question about the post-outlining IR. To change the example to one where the bait won't get outlined, suppose you had int foo(int a, int b) { try { try { maybe_throw(); return 0; } catch (int) { // some code here that gets outlined } L1: return a + b; } catch (float) { // some other code here that also gets outlined } L2: return (a + b) + 1; } and suppose that nothing gets moved around before outlining. Then, after outl...

...he eh.actions call's > block which [if I'm following correctly] won't actually get executed at > runtime). > > > > For example, given something like > > > > int foo (int a, int b) { > > int x; > > try { > > x = a + b; > > maybe_throw(); > > return 0; > > } catch (int) { > > return x; > > } catch (float) { > > return x + 1; > > } > > } > > > > Do you need to worry that something like partial deadcode elimination > could want to move the definition of x do...

Hi Reid, I’ve worked through a few scenarios, and I think this is converging. I’m attaching a new example, which extends the one we’ve been working through to handle a few more cases. I wasn’t sure what you intended the first i32 argument in an llvm.eh.actions entry to be. I’ve been using it as a place to store the eh state that I’m associating with the action, but that’s kind of circular