[LLVMdev] landingpad instruction documentation is vague

[Duncan Sands]

Hi Yuri,

On 11/01/12 22:44, Yuri wrote:
> On 01/11/2012 02:37, Duncan Sands wrote:
>>> 1. What happens when actual exception type isn't listed in catch or
>>> filter clauses? Does it still return the corresponding structure like if
>>> it was listed? Or behavior is undefined?
>> if it doesn't match a clause then the exception continues to be unwound.
>> Note that you can match a catch clause without being equal to the type
>> in the catch clause (for example because the catch clause type represents
>> some class B, and thus will also match a class A if B derives from A).
>
> This also means, that in case of multiple exception types handled by one
> landingpad instruction, type checking is essentially done twice now, once in the
> landingpad (to match catch or filter), and once more in the code that branches
> to the handler of the particular type after the landingpad. Before checking was
> done only once. I think, because of this, new landingpad mechanism has lower
> performance?

there are two steps: the unwinder uses the language specific personality
function to see if the exception object matches a catch clause.  If it does, it
identifies which catch clause matched using an integer (called the selector
value), and branches to the landing pad, passing the landing pad two values:
a pointer to the exception object, and the selector value.  So far this has
nothing to do with LLVM, it's just how Dwarf unwinding works.  At this point,
LLVM has the selector value and needs to branch to the code for the catch
clause based on this.  It does this via a series of comparisons and branches
(it could alternatively use a switch).  These comparisons aren't comparing
C++ types (that was done by the personality function), they are comparing
integer values.  This is pretty quick.  In any case it has to be done, and
needless to say GCC does exactly the same thing.

>
>>> 3. What are the allowed values and types passed to catch clause? I see
>>> that practically type is i8* and value is bitcast (i8** @<typeinfo> to
>>> i8*). Is this target specific? If yes, documentation should mention
>>> this, if not, it should describe them.
>> No, it's not target specific and in fact any pointer type is OK for a catch
>> clause. Clang has no need to bitcast to i8* in general, probably it is a
>> historical hangover from the previous exception handling scheme which did
>> require i8*. The dragonegg frontend doesn't do such bitcasts and works
>> perfectly fine.
>
> But the value should always be some @<typeinfo>, can't be anything else?

Yes, it needs to be a global variable.  However it doesn't have to be a global
variable of any specific type.  For example the Ada frontend mostly uses some
complicated global variables, but for Ada's "catch all" it uses a global
variable of integer type.

> Another question, if landingpad has 'cleanup' flag set, is it required or
> expected that resume instruction should follow?

It's not required by LLVM.  What were you planning to do?

Ciao, Duncan.