[LLVMdev] RFC: New EH representation for MSVC compatibility

[Reid Kleckner]

On Mon, May 18, 2015 at 11:48 AM, Steve Cheng <steve.ckp at gmail.com> wrote:

> On 2015-05-18 13:32:54 -0400, Reid Kleckner said:
>
>>
>> Right, doing our own personality function is possible, but still has half
>> the challenge of using __CxxFrameHandler3, and introduces a new runtime
>> dependency that isn't there currently. Given that it won't save that much
>> work, I'd rather not introduce a dependency that wasn't there before.
>>
>> The reason it's still hard is that you have to split the main function up
>> into more than one subfunction.
>>
>
> I see, but I thought are able to outline cleanup code already?
>

We can, but frankly it's unreliable. The new representation should help
make the job easier.


> And that the hiccup you are encountering is because __CxxFrameHandler3
> requires unwind tables with properly-ordered state transitions? The
> compiler SEH personality (_C_specific_handler) doesn't have that, right? If
> you could manage __try, __finally already, doesn't that provide the
> solution?
>

Right, __CxxFrameHandler3 is a lot more constraining than
__C_specific_handler. The SEH personality doesn't let you rethrow
exceptions, so once you catch the exception you're done, you're in the
parent function. My understanding is that C++ works by having an active
catch handler on the stack.


> Let me be precise. Let's take your example with the "ambiguous IR
> lowering":


I snipped the example, but in general, yes, I agree we could do another
personality with a less restrictive table format. I'm still not convinced
it's worth it.

 The exception object is allocated in the frame of the function calling
>> __CxxThrow, and it has to stay alive until control leaves the catch block
>> receiving the exception.
>> This is different from Itanium, where the exception object is constructed
>> in heap memory and the pointer is saved in TLS. If this were not the case,
>> we'd use the __gxx_personaltity_v0-style landingpad approach and make a new
>> personality variant that understands MS RTTI.
>>
>
> I'm surprised, I really want to check this myself later this week. I
> always thought that MSVCRT always copied your exception object because I
> have always seen it invoking the copy constructor on throw X. (It was a
> pain in my case because I didn't really want my exception objects to be
> copyable, only movable, and at least VS 2010 still insisted that I
> implement a copy constructor.)
>

Right, the type does have to be copyable. I think it's supposed to be
copied as part of the throw-expression, but if not, then it has to go fill
out the CatchableType tables, which have copy constructors in them. Anyway,
I might be wrong about where precisely the exception lives in memory, but
I'm sure the catches are outlined to support rethrow.


> Furthermore, the "catch info" in the MS ABI does have a field for the
> destructor that the catch block has to call. It's not theoretical, I've got
> code that calls that function pointer so I can properly catch C++
> exceptions from a SEH handler. Though I might be mistaken in that the field
> points to just an in-place destructor and not a deleting destructor.
>

Yep.


> Also, I thought the stack already is unwinded completely when you reach
> the beginning of the catch block (but not a __finally block, i.e. the
> cleanup code). At least, that's the impression I get from reading
> reverse-engineered source code for the personality functions and the
> Windows API RtlUnwindEx.


For __try / __except, yes, the stack is unwound at the point of the
__except. For try / catch, the stack unwinds after you leave the catch body
by fallthrough, goto, break, continue, return or whatever else you like,
because after that point you cannot rethrow anymore.

We could try to do all this outlining in Clang, but that blocks a lot of
>> LLVM optimizations. Any object with a destructor (std::string) is now
>> escaped into the funclet that calls the destructor, and simple
>> transformations (SROA) require interprocedural analysis. This affects the
>> code on the normal code path and not just the exceptional path. While EH
>> constructs like try / catch are fairly rare in C++, destructor cleanups are
>> very, very common, and I'd rather not pessimize so much code.
>>
>
> Right, but __CxxFrameHandler3 already forces you to outline destructor
> cleanups into funclets. So if you wanted to stop doing that you have to
> write your own personality function right?
>

No, I believe if we want to be able ABI compatible, we need to outline at
least destructor cleanups, regardless of what personality we use.


> What I am saying is, if you can design the personality function so that it
> works naturally with LLVM IR --- which can't see the source-level scopes
> --- that seems a whole lot less work versus:
>
> * Changing the existing Itanium-based EH model in LLVM
> * Incurring the wrath of people who like the Itanium model
> * Having to maintain backwards compatibility or provide an upgrade path
>

So, the nice thing about this design is that there are no scopes in normal
control flow. The scoping is all built into the EH blocks, which most
optimization passes don't care about. If you do a quick search through
lib/Transforms, you'll see there are very few passes that operate on
LandingPadInst and ResumeInst. Changing these instructions is actually
relatively cheap, if we can agree on the new semantics.


> Also, I think, if we want to eventually support trapped operations (some
> kind of invoke div_with_trap mentioned in another thread), wouldn't it be
> way easier to implement and optimize if the personality function can be
> designed in the right way?


Right, asynch exceptions are definitely something that users keep asking
for, so I'd like to see it done right if we want to do it at all. I think
this change is separable, though. Asynch exceptions have a lot more to do
with how you represent the potentially trapping operations (BB unwind
labels, lots of invoked-intrinsics, more instructions) than how you
represent the things to do on exception.

Thanks for taking a look!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150518/c91e0774/attachment.html>