<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 18, 2015 at 11:48 AM, Steve Cheng <span dir="ltr"><<a href="mailto:steve.ckp@gmail.com" target="_blank">steve.ckp@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015-05-18 13:32:54 -0400, Reid Kleckner said:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
The reason it's still hard is that you have to split the main function up into more than one subfunction.<br>
</blockquote>
<br></span>
I see, but I thought are able to outline cleanup code already?<br></blockquote><div><br></div><div>We can, but frankly it's unreliable. The new representation should help make the job easier.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let me be precise. Let's take your example with the "ambiguous IR lowering":</blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
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.<br>
</blockquote>
<br></span>
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.)<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>Yep.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></span>
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?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
* Changing the existing Itanium-based EH model in LLVM<br>
* Incurring the wrath of people who like the Itanium model<br>
* Having to maintain backwards compatibility or provide an upgrade path<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?</blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks for taking a look!</div></div></div></div>