[PATCH] Initial SEH IR generation implementation

[Reid Kleckner]

>>! In D5607#13, @rjmccall wrote:
> I think the best solution here is definitely to let the backend handle outlining handler functions: to get reasonable code, the outlining has to be done by something that understands the layout of the outer function's frame, and only the backend can do that.  No high-level intrinsic can capture the relationship between the functions in any sort of reliable way without completely disabling inlining of the outer function.  And we really want to still be able to do data-flow optimizations in the outer function; we just have to ensure that any live-in values have been spilled to the stack at the call site.

I agree, this is the right representation for catches and cleanups for the reasons you mention. I also don't want to introduce a new EH representation that is only used by SEH.

> Unfortunately, I think the same principle is going to end up applying to filter functions.  If they don't use values from the enclosing frame, then fine, you can outline them in the frontend; but if they do there's just no way that a frontend solution is ever going to work.  This might mean that we need to change the invoke IR pattern again so that the filter functions are just basic blocks within the function (which end in some special intrinsic/instruction that guides outlining).

OK. I was thinking that cleanups are common (C++ destructors) while `__try` and `__except` filter expressions are rare. Therefore we can do something slow and dumb in the frontend for them. But, if we have to implement late outlining for EH handlers, we might as well extend it to filter expressions. `__try` bodies will still be outlined for simplicity.

> I think you need to have that conversation on the LLVM side before you can make any useful progress on the Clang side.  Please CC me on that conversation when you start it.

Sure.

http://reviews.llvm.org/D5607