[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