llvm dev - Jan 2012 - [LLVMdev] landingpad instruction documentation is vague

I am new to the landingpad (which is relatively new too).
Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some 
questions open:

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?
2. What is 'somety'? Shouldn't it maybe say "result_type"
instead? In
the instructions printed by clang++, somety is { i8*, i32 }.
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.
4. Example in documentation shows catch clause as "catch i8** @_ZTIi" 
and clang++ generated example shows "catch i8* bitcast (i8** @_ZTIi to
i8*)"

Yuri

Hi Yuri,
> I am new to the landingpad (which is relatively new too).
> Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some
> questions open:
>
> 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).
> 2. What is 'somety'? Shouldn't it maybe say
"result_type" instead? In
> the instructions printed by clang++, somety is { i8*, i32 }.
The type is not specified to allow for exotic exception handling schemes
in which returning something funky is useful.  The code generators only
support Dwarf exception handling and setjmp/longjmp exception handling
which both use { i8*, i32 }, so while you can use any type in the IR,
only this type will work if you use the LLVM code generators to produce
code for your machine.  Note that the language reference explicitly says
"The resultval has the type somety".
> 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.
> 4. Example in documentation shows catch clause as "catch i8**
@_ZTIi"
> and clang++ generated example shows "catch i8* bitcast (i8** @_ZTIi to
i8*)"
See point 3.

Ciao, Duncan.

On Wed, Jan 11, 2012 at 11:37:50AM +0100, Duncan Sands
wrote:
> Hi Yuri,
> 
> > I am new to the landingpad (which is relatively new too).
> > Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves
some
> > questions open:
> >
> > 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).
[snippet]

  It would be great if this can be put somewhere on the website to clear
LLVM exception handling further. ;)

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

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