[LLVMdev] landingpad instruction documentation is vague

Yuri yuri at rawbw.com
Wed Jan 11 13:44:02 PST 2012


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?

>> 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?

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

Yuri



More information about the llvm-dev mailing list