[LLVMdev] LLVMdev Digest, Vol 85, Issue 50

Peter Lawrence peterl95124 at sbcglobal.net
Thu Jul 28 10:06:16 PDT 2011

        something to laugh about.....

I had originally mis-read the llvm eh doc concerning llvm.eh.selector  
and llvm.eh.typeid.for,

they are clearly documented as returning something like an index into  
a type table  (in our
case specifically a DWARF Types Table index),

but I had mis-read llvm.eh.selector to mean it returned the index /  
ordinal of which parameter
in its parameter list (not which type in the Type Table) was a match.

this lead to substantial confusion on my part about what "magic" was  
taking place during CodeGen.

-Peter Lawrence.

On Jul 28, 2011, at 1:41 AM, Bill Wendling wrote:

>> 5) its not clear from your email what is done with the result  
>> value of the landingpad instruction,
>> but I presume that your intent is that this does not change from  
>> the current scheme where
>> the "llvm.eh.typeid.for()" is called and its result is compared  
>> with the landingpad instruction's
>> result...
> 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.
>> ...and then a miracle happens in CodeGen, and most of the  
>> intrinsics are thrown away and the
>> hard register contents at the resumption at a landingpad from an  
>> Unwind include the value that
>> llvm.eh.typeid.for() would have returned...
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110728/3bab677e/attachment.html>

More information about the llvm-dev mailing list