[LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR

[Reid Kleckner]

I went ahead and implemented @llvm.frameallocate in a patch here:
http://reviews.llvm.org/D6493

Andrew, do you have a wip patch for outlining, or any lessons learned from
attempting it? I think outlining is now the next step, so let me know if
there's something you're actively working on so I can avoid duplicated
effort. :)

On Tue, Nov 25, 2014 at 3:09 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:

>  > We should also think about how to call std::terminate when cleanup
> dtors throw. The current representation for Itanium is inefficient. As a
> strawman, I propose making @__clang_call_terminate an intrinsic:
>
> …
>
>
>
> That sounds like a good starting point.
>
>
>
>
>
> > Chandler expressed strong concerns about this design, however, as
> @llvm.eh.get_capture_block adds an ordering constraint on CodeGen. Once you
> add this intrinsic, we *have* to do frame layout of @_Z13do_some_thingRi
> *before* we can emit code for all the callers of
> @llvm.eh.get_capture_block. Today, this is easy, because module order
> defines emission order, but in the great glorious future, codegen will
> hopefully be parallelized, and then we've inflicted this horrible
> constraint on the innocent.
>
>
>
> > His suggestion to break the ordering dependence was to lock down the
> frame offset of the capture block to always be some fixed offset known by
> the target (ie ebp - 4 on x86, if we like that).
>
>
>
> Chandler probably has a better feel for this sort of thing than I do.  I
> can’t think of a reason offhand why that wouldn’t work, but it makes me a
> little nervous.
>
>
>
> What would that look like in the IR?  Would we use the same intrinsics and
> just lower them to use the known location?
>
>
>
> I’ll think about this, but for now I’m happy to just proceed with the
> belief that it’s a solvable problem either way.
>
>
>
> >> For C++ exception handling, we need cleanup code that executes before
> the catch handlers and cleanup code that excutes in the case on uncaught
> exceptions.  I think both of these need to be outlined for the MSVC
> environment. Do you think we need a stub handler to be inserted in cases
> where no actual cleanup is performed?
>
> > I think it's actually harder than that, once you consider nested trys:
>
> > void f() {
>
> >  try {
>
> >    Outer outer;
>
> >    try {
>
> >      Inner inner;
>
> >      g();
>
> >    } catch (int) {
>
> >      // ~Inner gets run first
> >    }
>
> >  } catch (float) {
>
> >    // ~Inner gets run first
>
> >    // ~Outer gets run next
> >  }
>
> >  // uncaught exception? Run ~Inner then ~Outer.
> > }
>
>
>
> I took a look at the IR that’s generated for this example.  I see what you
> mean.  So there is potentially cleanup code before and after every catch
> handler, right?
>
>
>
> Do you happen to know offhand what that looks like in the .xdata for the
> _CxxFrameHandler3 function?
>
>
>
> -Andy
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141203/3df00102/attachment.html>