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

Reid Kleckner rnk at google.com
Tue Apr 21 15:23:01 PDT 2015


================
Comment at: lib/CodeGen/WinEHPrepare.cpp:427
@@ +426,3 @@
+        // The next BB is normal control flow.
+        Worklist.insert(BB->getTerminator()->getSuccessor(0));
+        break;
----------------
andrew.w.kaylor wrote:
> 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.
Yes, it is another Itanium divergence. We probably want to rename these intrinsics, as they are pretty WinEH specific at this point.

By backend passes, I'm assuming you mean the LLVM IR mid-level optimization passes? Everything in lib/CodeGen had to be redone, so we didn't save anything there. At this point, now that I can see the difficulties entailed in implementing WinEHPrepare, I'm happy to move to some other mid-level representation that doesn't resemble Itanium EH, even if we have to change the mid-level passes somewhat.

The main thing that I want to preserve is that we should outline late to support optimization. If we can't run SROA on objects with destructors because they are all escaped to an uninlineable call to the destructor on the exceptional codepath, all follow-on optimization is dead in the water. I don't want to have to make an interprocedural version of SROA or teach SROA to be (slightly) interprocedural. If we can't run SROA on objects with destructors, we will never be able to promote the heap memory from unique_ptr<int> to an i32 alloca by matching up the new/delete pairs, for example.

Ultimately, I think we can save ourselves the Itanium-style EH hoop jumping by switching to landingswitch (alternatively named "dispatchblock"), or something like it.

http://reviews.llvm.org/D9158

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






More information about the llvm-commits mailing list