[PATCH] [WinEH] Demote values live across exception handlers up front

[Andy Kaylor]

================
Comment at: lib/CodeGen/WinEHPrepare.cpp:427
@@ +426,3 @@
+        // The next BB is normal control flow.
+        Worklist.insert(BB->getTerminator()->getSuccessor(0));
+        break;
----------------
rnk wrote:
> andrew.w.kaylor wrote:
> > This doesn't seem right.  A nested landing pad block generally begins with a call to endcatch, but it isn't a normal block.
> I think we should stop emitting those endcatch calls in the frontend. I don't think they help identify regions to outline. They way I see it, barring code commoning optimizations, the handlers are just the BBs delimited by the begincatch / endcatch calls. A nested landingpad simply starts a new set of handlers.
That's a further divergence from the Itanium model, which I believe does need that call, but I guess we've got enough of those now that one more wouldn't matter.

We're jumping through a fair number of hoops to maintain at least a semblance of conformance to the basic structure of the Itanium model.  My understanding is that the primary benefit of this is that the back end passes know how to handle landing pads and we don't need to teach them something new.  Is that right?  I suppose it doesn't matter much which intrinsics we use along the way.

================
Comment at: lib/CodeGen/WinEHPrepare.cpp:508
@@ +507,3 @@
+    }
+    new StoreInst(Arg, Slot, AllocaInsertPt);
+  }
----------------
rnk wrote:
> andrew.w.kaylor wrote:
> > Is this inserting the store in the entry block?  That doesn't sound right.
> Why not? Arguments are SSA values that are defined once at function entry. This is only less than optimal when you have paths through the function that don't reach an invoke with a handler using the argument.
> 
> We could try to sink the store somewhere closer to a dominating invoke to stay out of any fast paths through the funciton, but we'd want to stay hoisted out of any loop bodies. This analysis seems hard and not really worth it. If you're still concerned, an easier direction might be to have llvm.argument.escape and llvm.argument.recover intrinsics to recover the address of the argument and ensure that the parent homes escaped register parameters.
Oh, nevermind.  I was seeing 'argument' but thinking 'operand' because of where this set was originally populated, which also explains the irrelevancy of my comment above.  Sorry about that.

http://reviews.llvm.org/D9158

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/