[llvm-commits] [Patch] Exception Handling Documentation

[Chris Lattner]

On Jul 31, 2011, at 7:14 PM, Bill Wendling wrote:

> Attached is an updated version of the LangRef.html doc. It explains the "landingpad" instruction, links to the exception handling overview in the ExceptionHandling.html doc, and modifies the 'invoke' instruction's explanation to include a paragraph on the landingpad instruction.
> 
> Please review. :-)

This reads funnily:

+ The "<tt>landingpad</tt>"
+   instruction's restrictions tightly couples it to the "<tt>invoke</tt>"
+   instruction

How about:

The restrictions on the "<tt>landingpad</tt>" instruction tightly couples it to the "<tt>invoke</tt>"
+   instruction

@@ -3372,17 +3384,18 @@
    successors.</p>
 
 <h5>Arguments:</h5>
-<p>The '<tt>resume</tt>' instruction's argument must have the same type as the
-   result of any '<tt>landingpad</tt>' instruction in the same function.</p>
+<p>The '<tt>resume</tt>' instruction requires one argument, which must have the
+   same type as the result of any '<tt>landingpad</tt>' instruction in the same
+   function.</p>

Thanks for mentioning this.  As a devil's advocate question: shouldn't this be forced to match the landingpad instruction that interrupted the unwind?  isn't it theoretically possible to have code like this:


  invoke @somefunc  -> unwind %landingpadbb

landingpadbb:
  %A = landingpad ...
  call foo(%A)
  unreachable

void foo( ... %A) {
  resume %A
}

In other words, does the resume actually have to be in the same function as the landing pad?


+<h5>Syntax:</h5>
+<pre>
+  <resultval> = landingpad <somety> personality <type> <pers_fn> cleanup? <clause>+
+  <clause> := catch <type> <value> {, <type> <value>}*
+  <clause> := filter <type> <value> {, <type> <value>}*


I thought we dropped "cleanup" for now.  Also, it doesn't make sense to me to allow both lists of clauses and lists of values in each clause.  Is there any reason not to simplify this down to:

+  <resultval> = landingpad <somety> personality <type> <pers_fn><clause>+
+  <clause> := catch <type> <value>
+  <clause> := filter <type> <value>

?


The optional
+   <tt>cleanup</tt> flag indicates that the landing pad block is a cleanup.</p>

Again, I thought we were leaving this out of the first cut.


+  <li>A landing pad blcok must have a '<tt>landingpad</tt>' instruction as its
+      first non-PHI instruction.</li>
+  <li>The '<tt>landingpad</tt>' instruction must be the first non-PHI
+      instruction in the landing pad block.</li>

typo "blcok".  It's not clear to me what the difference between these two points is.


+  <li>Like indirect branches, splitting the critical edge to a landing pad block
+      requires considerable care, and <tt>SplitCriticalEdge</tt> will refuse to
+      do it.</li>

This shouldn't be in LangRef.html

 </div>
 </div>
+</div>

Something seems wrong here.  Why so many /div's?

Otherwise this looks great, please commit with the changes above if you agree.

-Chris