llvm dev - Dec 2010 - [LLVMdev] Inlining and exception handling in LLVM and GCC

Hi John,

On 07/12/10 01:01, John McCall wrote:
> On Dec 6, 2010, at 1:58 PM, Duncan Sands wrote:
>> The poor interaction between exception handling and inlining in LLVM is
one of
>> the main motivations for the new exception handling models proposed
recently.
>> Here I give my analysis of the origin of the problem in the hope of
clarifying
>> the situation.
>
> Your analysis coincides with the analysis I made when implementing EH
> in clang. I decided, however, that in the short term, given the brokenness
> of the IR, I would rather ignore the known bad consequences of emitting
> cleanups as catch-alls than deal with the uncertainties of whether codegen
> could consistently clean up after our broken inliner. I haven't yet
regretted
> this choice.
if I changed the inliner so it does its best to find the eh.selector for an
invoke, and propagates the information onto the things it inlines, would clang
make use of it (i.e. output cleanups rather than turning them into catch-alls)?

Ciao, Duncan.

On Dec 7, 2010, at 3:38 AM, Duncan Sands wrote:
> Hi John,
> 
> On 07/12/10 01:01, John McCall wrote:
>> On Dec 6, 2010, at 1:58 PM, Duncan Sands wrote:
>>> The poor interaction between exception handling and inlining in
LLVM is one of
>>> the main motivations for the new exception handling models proposed
recently.
>>> Here I give my analysis of the origin of the problem in the hope of
clarifying
>>> the situation.
>> 
>> Your analysis coincides with the analysis I made when implementing EH
>> in clang. I decided, however, that in the short term, given the
brokenness
>> of the IR, I would rather ignore the known bad consequences of emitting
>> cleanups as catch-alls than deal with the uncertainties of whether
codegen
>> could consistently clean up after our broken inliner. I haven't yet
regretted
>> this choice.
> 
> if I changed the inliner so it does its best to find the eh.selector for an
> invoke, and propagates the information onto the things it inlines, would
clang
> make use of it (i.e. output cleanups rather than turning them into
catch-alls)?
We'd still have problems — cleanups would have to chain with
_Unwind_Resume_or_Rethrow, because most of the platforms we support rely
on correct compiler use of _Unwind_Resume — but it might be worthwhile.

John.

Hi John,
>> if I changed the inliner so it does its best to find the eh.selector
for an
>> invoke, and propagates the information onto the things it inlines,
would clang
>> make use of it (i.e. output cleanups rather than turning them into
catch-alls)?
>
> We'd still have problems — cleanups would have to chain with
> _Unwind_Resume_or_Rethrow, because most of the platforms we support rely
> on correct compiler use of _Unwind_Resume — but it might be worthwhile.
OK, I'll see if I can come up with something reasonable (probably next week)
that we can at least play around with.

Ciao, Duncan.