[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
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
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.
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
> 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...
More information about the llvm-dev