[LLVMdev] Inlining and exception handling in LLVM and GCC

[John McCall]

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.