<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Bill,<div> something to laugh about.....</div><div><br></div><div>I had originally mis-read the llvm eh doc concerning llvm.eh.selector and llvm.eh.typeid.for,</div><div><br></div><div>they are clearly documented as returning something like an index into a type table (in our</div><div>case specifically a DWARF Types Table index),</div><div><br></div><div>but I had mis-read llvm.eh.selector to mean it returned the index / ordinal of which parameter</div><div>in its parameter list (not which type in the Type Table) was a match.</div><div><br></div><div>this lead to substantial confusion on my part about what "magic" was taking place during CodeGen.</div><div><br></div><div><br></div><div>-Peter Lawrence.</div><div><br></div><div><br></div><div><br></div><div><div><div>On Jul 28, 2011, at 1:41 AM, Bill Wendling wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Monaco; min-height: 16.0px"><br></p> <blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">5) its not clear from your email what is done with the result value of the landingpad instruction,</font></p> <p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">but I presume that your intent is that this does not change from the current scheme where</font></p> <p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">the "llvm.eh.typeid.for()" is called and its result is compared with the landingpad instruction's</font></p> <p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">result...</font></p> <p style="margin: 0.0px 0.0px 0.0px 10.0px; font: 12.0px Monaco; min-height: 16.0px"><br></p> </blockquote><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">The values the landingpad returns are those that are set by the personality function upon re-entry into the function. On X86, it's the EAX and EDX registers. One of those values is a pointer to the exception handling object. The other is a "selector" value, that we can then use to determine which (if any) of the clauses should be run.</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Monaco; min-height: 16.0px"><br></p> <blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">...and then a miracle happens in CodeGen, and most of the intrinsics are thrown away and the</font></p> <p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">hard register contents at the resumption at a landingpad from an Unwind include the value that</font></p> <p style="margin: 0.0px 0.0px 0.0px 10.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">llvm.eh.typeid.for() would have returned...</font></p> <p style="margin: 0.0px 0.0px 0.0px 10.0px; font: 12.0px Monaco; min-height: 16.0px"><br></p> </blockquote><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Monaco" size="3" style="font: 12.0px Monaco">The llvm.eh.typeid.for is a hold-over from the old design. It's returns a constant value that can be compared against the "selector" the personality function returns. It remains because it gives an explicit representation of how the decision table of which catch to call is executed. It's similar to a series of if-then-elses.</font></p> </blockquote></div><br></div></body></html>