<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I don’t know much about SEH and haven’t had time to really dig into this, but the idea of outlining functions that need to know about the frame layout sounds a bit scary. Is it really necessary?<div class=""><br class=""></div><div class="">I’m wondering if you can treat the cleanups and filter functions as portions of the same function, instead of outlining them to separate functions. Can you arrange to set up the base pointer on entry to one of those segments of code to have the same value as when running the normal part of the function? If so, from the code-gen point of view, doesn’t it just behave as if there is a large dynamic alloca on the stack at that point (because the stack pointer is not where it was when the function was previously running)? Are there other constraints that prevent that from working?<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 13, 2014, at 5:28 PM, Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 13, 2014 at 5:19 PM, Kaylor, Andrew<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:andrew.kaylor@intel.com" target="_blank" class="">andrew.kaylor@intel.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">I don’t really have a good enough feeling for the landingpad syntax yet to comment on the most natural way to extend it yet, but creating a synthetic cleanup function to call from the personality function is what I was thinking.</span></p></div></div></blockquote><div class=""><br class=""></div><div class="">Pretty much.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">With the current (trunk +/- a couple of weeks) clang, compiling for an “x86_64-pc-windows-msvc” target, I’m seeing a landingpad that looks like this:<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">lpad: ; preds = %if.end, %if.then<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> <span class="Apple-converted-space"> </span>%2 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*)<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> <span class="Apple-converted-space"> </span>cleanup<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> <span class="Apple-converted-space"> </span>%3 = extractvalue { i8*, i32 } %2, 0<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> <span class="Apple-converted-space"> </span>store i8* %3, i8** %exn.slot<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> <span class="Apple-converted-space"> </span>%4 = extractvalue { i8*, i32 } %2, 1<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> <span class="Apple-converted-space"> </span>store i32 %4, i32* %ehselector.slot<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> <span class="Apple-converted-space"> </span>call void @"\01??1Bob@@QEAA@XZ"(%class.Bob* %bob) #3 ; Calling the destructor for a class named “Bob”<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> <span class="Apple-converted-space"> </span>br label %eh.resume<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">Replacing __gxx_personality_v0 with the name of my custom personality function (which has the SEH signature) and scrubbing out the terminate and resume calls for the time being, I see my personality function being called twice -- first for the C++ exception (Exception code == 0xe06d7363) and once for the unwind. So now I just need to figure out how to get a pointer to a cleanup function into the DispatcherContext->HandlerData, which must be where the extra stuff in the landingpad comes in, right?</span></p></div></div></blockquote><div class=""><br class=""></div><div class="">It's got some docs here:</div><div class=""><a href="http://llvm.org/docs/ExceptionHandling.html#overview" class="">http://llvm.org/docs/ExceptionHandling.html#overview</a><br class=""></div><div class=""><br class=""></div><div class="">The two values are the exception pointer and the selector value. The selector value is an artifact of the way we model the Itanium EH scheme, and you can basically set it to zero if you only want to deal with cleanups for the time being. The exception pointer is presumably pulled from the arguments to the personality routine. Again, cleanups don't need it, so you can probably zero it too.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">Anyway, I think I’m making progress. :-)</span></p></div></div></blockquote><div class=""><br class=""></div><div class="">Nice! </div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><div class=""><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">-Andy<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><b class=""><span style="font-size: 10pt; font-family: Tahoma, sans-serif;" class="">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif;" class=""><span class="Apple-converted-space"> </span>Reid Kleckner [mailto:<a href="mailto:rnk@google.com" target="_blank" class="">rnk@google.com</a>]<span class="Apple-converted-space"> </span><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Thursday, November 13, 2014 4:22 PM</span></p><div class=""><div class="h5"><br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Kaylor, Andrew<br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>LLVM Developers Mailing List; John McCall<br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR<u class=""></u><u class=""></u></div></div><div class=""><br class="webkit-block-placeholder"></div><div class=""><div class="h5"><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div class=""><p class="MsoNormal">Focusing on cleanups is probably a good way to start. The trouble is that your personality function can't just reset rsp and jump to the landing pad, or it will trash the state of the unwinder that's still on the stack. Everything in the landing pad basically has to be outlined. If the outlining happens at the IR level, we need some way to represent that, and I don't really have it nailed down.<u class=""></u><u class=""></u></p><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Here's an idea, just to brainstorm:<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">define void @parent() {<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>invoke ... unwind to %lpad<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>...<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">lpad:<u class=""></u><u class=""></u></p><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>%eh_vals = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__C_specific_handler to i8*)<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>cleanup<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>catch i8* @typeid1<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>catch i8* @typeid2<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>%label = call i8* (...)* @llvm.eh.outlined_handlers(<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>void (i8*, i8*)* @my_cleanup,<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>i8* @typeid1, i8* (i8*, i8*)* @my_catch1,<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>i8* @typeid2, i8* (i8*, i8*)* @my_catch2)<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>indirectbr i8* %label<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">endcatch:<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>...<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">}<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><div class=""><p class="MsoNormal">define void @my_cleanup(i8*, i8*) {<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>...<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>ret void ; unwinder will keep going for cleanups<br class="">}<u class=""></u><u class=""></u></p></div></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">define i8* @my_catch1(i8*, i8*) {<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>ret i8* blockaddress(@parent, %endcatch) ; merge back into normal flow at endcatch<br class="">}<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><div class=""><p class="MsoNormal">define i8* @my_catch2(i8*, i8*) {<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <span class="Apple-converted-space"> </span>ret i8* blockaddress(@parent, %endcatch) ; merge back into normal flow at endcatch<br class="">}<u class=""></u><u class=""></u></p></div></div></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">I guess @llvm.eh.outlined_handlers wouldn't be valid outside a landing pad, and would only be introduced during CodeGenPrepare to allow the best optimization of the handlers in the context of the parent function.<u class=""></u><u class=""></u></p></div></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div class=""><p class="MsoNormal">On Thu, Nov 13, 2014 at 3:25 PM, Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank" class="">andrew.kaylor@intel.com</a>> wrote:<u class=""></u><u class=""></u></p><div class=""><div class=""><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">Thanks for the additional information.</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">Right now I’m experimenting with a mix of code compiled with MSVC and code compiled with clang, trying to get a C++ exception thrown and caught by the MSVC-compiled code across a function in the clang-compiled code. My goal here is to isolate a small part of what needs to be done in a way that lends itself to tinkering. I think this might lead me to the outlining of EH blocks that you describe below.</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">If the clang code doesn’t have and exception handler (and it can’t since clang won’t compile that right now) and doesn’t need to do any clean-up, this works fine. If the clang code does need to do cleanup, clang currently emits the same landingpad stuff that it would emit for mingw and since I’m trying to link with the MSVC environment I end up with unresolved externals. So I’m playing around with the clang-generated IR to see if I can turn it into something that will handle the cleanup and let the exception pass. I’ve got it calling my custom SEH-style personality function and it’s trivial to get that to let the exception pass without doing the cleanup. Now I just need to figure out how to get it to execute the cleanup code.</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">I haven’t spent a lot of time on this yet, so if this overlaps with what you’ve been doing I can step back and approach it from a different direction. Otherwise, I’ll proceed and see if I can make use of your suggestions below with regard to outlining, probably starting with manual changes to the IR that simulate the process.</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">-Andy</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><b class=""><span style="font-size: 10pt; font-family: Tahoma, sans-serif;" class="">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif;" class=""><span class="Apple-converted-space"> </span>Reid Kleckner [mailto:</span><a href="mailto:rnk@google.com" target="_blank" class=""><span style="font-size: 10pt; font-family: Tahoma, sans-serif;" class="">rnk@google.com</span></a><span style="font-size: 10pt; font-family: Tahoma, sans-serif;" class="">]<span class="Apple-converted-space"> </span><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Thursday, November 13, 2014 11:51 AM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Kaylor, Andrew<br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>LLVM Developers Mailing List; John McCall<br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR</span><u class=""></u><u class=""></u></p><p class="MsoNormal"> <u class=""></u><u class=""></u></p><div class=""><div class=""><div class=""><p class="MsoNormal">Cool! Apologies for the following stream of consciousness brain dump...<u class=""></u><u class=""></u></p></div><div class=""><div class=""><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">On Wed, Nov 12, 2014 at 5:07 PM, Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank" class="">andrew.kaylor@intel.com</a>> wrote:<u class=""></u><u class=""></u></p></div><div class=""><blockquote style="border-style: none none none solid; border-left-color: rgb(204, 204, 204); border-left-width: 1pt; padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">Hi Reid,</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">I’ve been following your proposal, and I’d be interested in helping out if I can. My main interest right now is in enabling C++ exception handling in clang for native (i.e. not mingw/cygwin) Windows targets (both 32-bit and 64-bit), but if I understand things correctly that will be closely related to your SEH work under the hood.</span><u class=""></u><u class=""></u></p></div></div></blockquote><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">Great! I agree, any changes to LLVM IR made to support SEH will also be needed to support C++ exceptions on Windows, in particular the outlining.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">In the current LLVM model, all the exception handling code lives in the landing pad. The Windows unwinder doesn't actually return control to the landingpad until very late. Instead, it creates new stack frames to invoke the cleanup, catch handler (C++ EH only), or filter function (SEH only). This is why we need to have outlining somewhere. The question is, where should we do it? Personally, I want to do this on LLVM IR during CodeGenPrepare.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">The major challenge that outlining anywhere presents is that now the outlined code has to "know" something about the frame layout of the function it was outlined from in order to access local variables. I think we can add `i8* @llvm.eh.get_capture_block(i8* %function, i8* %parent_rbp)` and `void @llvm.eh.set_capture_block(i8* %captures)` intrinsics to make this work. Any SSA values or allocas captured by the outlined landing pad code will be demoted to memory and stored in the capture block, and the layout will be encoded in a struct used by the outlined handlers and the parent function. However, once you do this, you cannot inline the IR without some heroics. It probably isn't that important to be able to inline functions with try/catch, but a good acid test for any new LLVM IR construct is "will it inline?", and this construct fails. I think we can live with this construct as long as we only introduce it after CodeGenPrepare.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">The remaining wrinkle in the capture block scheme is stack realignment prologues. In this case, we have three pointers to the stack: the SP, the base pointer (esi/rbx), and the frame pointer (ebp/rbp). Is the capture block stored at a known constant offset from ebp/rbp or esi/rbx? Or do we load and store a dynamic offset saved somewhere near ebp/rbp? This needs study.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><blockquote style="border-style: none none none solid; border-left-color: rgb(204, 204, 204); border-left-width: 1pt; padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">I’m still trying to get up to speed on what is and is not implemented, but I think I’m starting to get a clear picture. My understanding is that LLVM has the necessary support to emit exception handling records that Windows will be able to work with (for Win64 EH) but some work may be required to get the IR properly wired up, and that there’s basically nothing in place to support Win32 EH and nothing in clang to generate the IR for either case. Is that more or less accurate?</span><u class=""></u><u class=""></u></p></div></div></blockquote><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">We can emit valid pdata and xdata sections on Win64, and this supports basic stack unwinding. On top of that, we currently follow mingw64 and use Itanium-style LSDA tables and the __gxx_personality_seh0 personality function to run EH handlers. This means the standard exception handling IR emitted by clang and other frontends "just works" on Windows, and I want to keep it that way. I think most of the changes should be on the LLVM side to lower the standard EH IR down to something that is more compatible with MSVC EH.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><blockquote style="border-style: none none none solid; border-left-color: rgb(204, 204, 204); border-left-width: 1pt; padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">I’ve been looking at the work Kai Nacke did in ldc to implement exception handling there, but it isn’t clear to me yet how relevant that is to clang.</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">Can you tell me more about what your plans are? Specifically, do you intend to support both 32 and 64 bit targets? And were you also planning to work toward C++ exception handling support in clang once you had the general SEH support in place?</span><u class=""></u><u class=""></u></p></div></div></blockquote><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">I want to do Win64 first because it is easier and better documented, and then look at 32-bit next. 32-bit SEH does things like "take the address of a BB label from the middle of the parent function and 'call' it with a special ebp value passed in", but that is basically equivalent to the Win64 way of doing things with a very special calling convention.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">I know some people are also interested in ARM (WoA), which should be similar to Win64, as it also uses pdata/xdata style unwind info.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><blockquote style="border-style: none none none solid; border-left-color: rgb(204, 204, 204); border-left-width: 1pt; padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">Finally, and most importantly, what can I do to help?</span><u class=""></u><u class=""></u></p></div></blockquote><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">I think there are some separable tasks here. <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">The EH capture block intrinsics can probably be built in isolation from the outlining. We can probably make `get_capture_block` work with the result of `@llvm.frameaddress(i32 0)`. The inliner also has to be taught to avoid inlining functions that set up a capture block.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">Doing outlining will be similar what `llvm::CloneAndPruneFunctionInto` does, except it will start at the landing pad instead of the entry block. Instead of mapping from parameters to arguments, the outliner would map the selector to a constant and propagate that value forwards, pruning conditional branches as it goes. The `resume` instruction would end outlining and become a `ret`. Any cloned `ret` instructions are the result of cloning something that is statically reachable but dynamically unreachable. We can transform them to `unreachable` and run standard cleanup passes to propagate that backwards.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">32-bit x86 EH will require installing an alloca onto the fs:00 chain of EH handlers. I suppose this could be emitted during CodeGenPrepare as regular LLVM IR instructions, since we have a way of writing `load/store fs:00` with address space 257. This alloca should probably be the same as the capture block, since it has to be at some known offset from ebp.<u class=""></u><u class=""></u></p></div></div></div></div></div></div></div></div></div><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div></div></div></div></div></blockquote></div><br class=""></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">LLVM Developers mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" class="">http://llvm.cs.uiuc.edu</a></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></span></div></blockquote></div><br class=""></div></div></body></html>