Bill et al,
I haven't really thought this through (I've never
been a fan of exception specifications),
but it seems that inlining functions that do have exception
specifications, and hence filter
operands in their landing-pads, isn't so obvious...
if you want to inline
void foo () throw() { ... } // empty throw() list means "no-throw"
into a function that does allow exceptions to be propagated out, then
you'll have a hard time
combining their landing pads !
it seems, at least on first thought, that having more than one filter
list in a landing pad isn't
useful ? (assuming the only way to get more than one is from
inlining ?)
-Peter Lawrence.
On Aug 3, 2011, at 12:35 AM, llvmdev-request at cs.uiuc.edu wrote:
>> yes there is something about the order :) When front-ends output
>> code, all
>> catches come before filters, but after inlining you can get:
>> catches, filters,
>> catches, filters etc and this ordering needs to be preserved.
>> Also, filters
>> are different from catches: filter ty_1, ty_2, ..., ty_N matches
>> any exception
>> that would not be caught by any of ty_1, ty_2, ..., ty_N. This is
>> quite
>> different to filter ty_1, filter ty_2, ..., filter ty_N. For
>> example, suppose
>> you throw ty_2. Then the filter ty_1, ty_2, ..., ty_N wouldn't
>> match that,
>> but filter ty_1 would.
>>
>> So filter ty_1, ..., ty_N makes sense; but I don't think catch
>> ty_1, ..., ty_N
>> makes sense.
>
> Agreed. Other notes: a zero-type filter is meaningful (and pretty
> common ? it's the result of 'throw()'), but the ordering of the
> cleanup
> bit is not, so I would suggest this grammar:
>
> Instruction ::= 'landingpad' Type 'personality'
TypeAndValue
> 'cleanup'? LandingPadClause*
> LandingPadClause ::= 'catch' TypeAndValue
> LandingPadClause ::= 'filter' TypeAndValue*
>
> John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110804/d7b3b31d/attachment.html>
On Aug 4, 2011, at 2:03 PM, Peter Lawrence wrote:> Bill et al, > I haven't really thought this through (I've never been a fan of exception specifications), > but it seems that inlining functions that do have exception specifications, and hence filter > operands in their landing-pads, isn't so obvious... > > if you want to inline > > void foo () throw() { ... } // empty throw() list means "no-throw" > > into a function that does allow exceptions to be propagated out, then you'll have a hard time > combining their landing pads ! > > it seems, at least on first thought, that having more than one filter list in a landing pad isn't > useful ? (assuming the only way to get more than one is from inlining ?) >The exception tables are set up to allow for multiple exception specifications per function. So if we inline a function with exception spec of A, B, C into one with an exception spec of D, E then it's totally doable. The table will look something like this: A B C 0 D E 0 And the "action" part of the table will point to the correct exception spec start (A or D) depending on what state the exception is at a given time. (I.e., is it in a "resume" situation or "catch" situation.) -bw
Bill,
I suspect we're talking about two different aspects,
I think you are saying that there is an ability for the DWARF Actions
Table
to contain multiple lists, including multiple filter lists - no
disagreement
there,
I am saying that for any one landing-pad it might not make sense
for it to be able to have more than one filter list.
-Peter Lawrence.
On Aug 4, 2011, at 2:38 PM, Bill Wendling wrote:
> On Aug 4, 2011, at 2:03 PM, Peter Lawrence wrote:
>
>> Bill et al,
>> I haven't really thought this through (I've
never
>> been a fan of exception specifications),
>> but it seems that inlining functions that do have exception
>> specifications, and hence filter
>> operands in their landing-pads, isn't so obvious...
>>
>> if you want to inline
>>
>> void foo () throw() { ... } // empty throw() list means
"no-throw"
>>
>> into a function that does allow exceptions to be propagated out,
>> then you'll have a hard time
>> combining their landing pads !
>>
>> it seems, at least on first thought, that having more than one
>> filter list in a landing pad isn't
>> useful ? (assuming the only way to get more than one is from
>> inlining ?)
>>
> The exception tables are set up to allow for multiple exception
> specifications per function. So if we inline a function with
> exception spec of A, B, C into one with an exception spec of D, E
> then it's totally doable. The table will look something like this:
>
> A
> B
> C
> 0
> D
> E
> 0
>
> And the "action" part of the table will point to the correct
> exception spec start (A or D) depending on what state the exception
> is at a given time. (I.e., is it in a "resume" situation or
"catch"
> situation.)
>
> -bw
>