<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Monaco; min-height: 16.0px"><br></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">What? Yet another EH proposal?! This one is different from the others in that</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">I'm planning to start implementing this shortly. But I want your feedback! I've</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others.</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">Now is your turn!</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Monaco; min-height: 16.0px"><br></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">Please read this proposal and send me your comments, suggestions, and concerns.</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Monaco; min-height: 16.0px"><br></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">-bw</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Monaco; min-height: 16.0px"><br></p> </blockquote></div><br><div>Bill,</div><div><br></div><div><br></div><div>1) it is good to see that the "exception regions" idea has been abandoned, it is mathematically</div><div>inconsistent with modern optimization theory, and at best would require extra passes to translate</div><div>into/outof that representation form.</div><div><br></div><div><br></div><div><br></div><div>2) it is good to see the prohibition of mixing by inlining of exception handing from different languages,</div><div>it has always been my thought that this cannot be well defined in general, different languages not</div><div>only have different control-flow semantics for exception handling, but the different type systems</div><div>(what is a derived type and what constitutes "type match" for exceptions) are not always going to be</div><div>compatible. </div><div><br></div><div><br></div><div><br></div><div><div>3) the other non-cosmetic portion of this proposal boils down to:</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>a) every invoke must point to a landingpad-block</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>b) every landingpad-block must start with a catch specification (LandingpadInst)</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>c) catch specifications (LandingpadInst) must not occur anywhere else</div><div><br></div><div>don't take "cosmetic" as a criticism, I think gcc suffers from bad cosmetics, and llvm benefits</div><div>from good cosmetics. The logic I see is that we already have PHINode and TerminateInst</div><div>that have explicit restrictions, so it makes sense that if catch-specifications have restrictions</div><div>they too should be Instructions rather than Intrinsics.</div><div><br></div><div><br></div><div><br></div><div>3.b) I have been thinking about other possible control-flow-graph invariants of the</div><div>landingpad blocks and the catch blocks that they lead to, but so far have not come up</div><div>with very muchl, I wonder if anyone else is thinking about this...?...</div><div><br></div><div>for example cleanups come before __cxa_begin_catch, but it isn't clear what is a cleanup</div><div>and what isn't other than what comes before a __cxa_begin_catch and what comes after ?</div><div><br></div><div>however, using that as the definition of cleanup, for C++ any InvokeInst that is so</div><div>identified as cleanup then its only operand has to be terminate (I think, someone</div><div>please correct me if I've made an incorrect conclusion here).</div><div><br></div><div><br></div><div><br></div><div>3.c) I have been thinking about whether the original source code structure of try-catch</div><div>statements can be reconstructed from the IR, are two try-catches nested, either in the</div><div>try or the catch part, or are they disjoint, and can the cleanups be identified as such at</div><div>the IR level or have things potentially been mixmastered up too much after optimization.</div><div>I wonder if anyone else is thinking about this also...?...</div><div><br></div><div><br></div><div><br></div></div><div>4) IIUC, llvm has inherited a bug from gcc where the debugger cannot let the user know an exception is</div><div>going to be uncaught until after the stack has been unwound -- contrary to the design intentions of the </div><div>unwind library that most exception implementations are based on (with a two phase unwind algorithm) --</div><div>which creates a problem for the debugger user.</div><div><br></div><div>so, the question is will there be a specific recognizable "catch all types" type that can occur in the</div><div>landingpad's catch list ?</div><div><br></div><div>and will there be a __llvm_personality_v0 that is designed to do the right thing for this case.</div><div><br></div><div>yes, I know this is a can-of-worms, it will break gcc compatibility, but then perhaps we can be the</div><div>motivation for gnu folks to fix their implementation, be the leader rather than the follower.!.</div><div><br></div><div><br></div><div>4.b) it is not at all clear from your write up what the "cleanup" option for a landingpad is, and</div><div>how this is used when both cleanups AND catches are necessary in a given try-catch source</div><div>code statement, including if one of the user specified catches is a catch-all.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>5) its not clear from your email what is done with the result value of the landingpad instruction,</div><div>but I presume that your intent is that this does not change from the current scheme where</div><div>the "llvm.eh.typeid.for()" is called and its result is compared with the landingpad instruction's</div><div>result...</div><div><br></div><div>...and then a miracle happens in CodeGen, and most of the intrinsics are thrown away and the</div><div>hard register contents at the resumption at a landingpad from an Unwind include the value that</div><div>llvm.eh.typeid.for() would have returned...</div><div><br></div><div>this is the sort of thing I'm talking about when I imply that the current scheme is poorly documented!</div><div><br></div><div><br></div><div>Also, what is going to happen for the case of cleanup AND catches, currently the result of not</div><div>only the llvm.eh.select() result is cached, but in fact the complete decoding of it relative to</div><div>all the llvm.eh.typeid.for() calls is cached, then the cleanup code executed, THEN finally the</div><div>already decoded value is used to "switch" from the landing pad to the correct catch-block.</div><div><br></div><div>who is going to generate all that code, is it still going to be explicit in the IR, or is CodeGen going</div><div>to now be responsible creating it.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>6) it would be nice if the existing UnwindInst could be retained. I wince at naming an instruction</div><div>"Resume" since in the English language it is so ambiguous (resume normal execution following</div><div>the conclusion of handing an exception, verses resume throwing an exception). IE cosmetics</div><div>do matter.</div><div><br></div><div><br></div><div><br></div><div>7) there are still lots of other intrinsics/routines involved:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>__cxa_allocate_exception</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>__cxa_throw, cxa_rethrow</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>__cxa_begin_catch(), __cxa_end_catch</div><div>although these particular ones seem to be the easiest to document as they do seem to be</div><div>translated verbatim (no CodeGen miracles).</div><div><br></div><div><br></div><div><br></div><div>8) I really like the idea of "terminate" being one of the options to the landingpad</div><div>instruction, it makes identification of abnormal code more direct (otherwise control-</div><div>flow analysis has to be done to see if __terminate() is reachable to conclude that</div><div>something is abnormal code, and I really don't like that analysis, it seems too error-</div><div>prone as __terminate() might be reachable for other reasons (not that I have come</div><div>up with such a scenario yet, but I think I might be able to), and this conclusion would</div><div>then be ambiguous).</div><div><br></div><div>Even if support for the terminate option required a new __llvm_personality_v0 and</div><div>a new Unwind library function, I am still in favor of having and using it. But I suspect</div><div>that CodeGen can lower this into the same old MC branch to a block that only contains</div><div>__terminate() that we currently see in IR, and a new personality and Unwind</div><div>aren't necessary, but would still be a nice optimization.</div><div><br></div><div><br></div><div><br></div><div><br></div><div>sincerely,</div><div>Peter Lawrence.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>