[LLVMdev] Alternative exception handling proposal

[John McCall]

On Dec 2, 2010, at 4:26 AM, Duncan Sands wrote:
>>> Inlining
>>> --------
>>> 
>>> Many a plausible seeming exception handling scheme has fallen by the way-side
>>> because it interacts poorly with inlining.
>>> 
>>> Here is how inlining would work with this scheme.  It's pretty close to how
>>> it works right now.  Suppose you have
>>> 
>>>   invoke void @foo()
>>>           to label %invcont unwind label %lpad<foo catch info>
>>> 
>>> and you want to inline foo.  Suppose foo contains an invoke:
>>> 
>>>   invoke void @bar()
>>>           to label %invcont2 unwind label %lpad2<bar catch info>
>>> 
>>> Then after inlining you have an invoke of bar in which foo's catch info
>>> has been appended to bar's:
>>> 
>>>   invoke void @bar()
>>>           to label %invcont2 unwind label %lpad2<joined catch info>
>>> 
>>> What does appending<foo catch info>  to<bar catch info>  mean?  If the
>>> personality functions are different then you are in trouble and need to
>>> disallow the inlining!  The cleanup flag is the "or" of the foo and bar
>>> cleanup flags.  The catches are the bar catches followed by the foo
>>> catches.
>> 
>> You are greatly underestimating the amount of work the inliner has to do under this proposal.  In fact, the only thing that your proposal simplifies is DwarfEHPrepare.
> 
> needless to say, I disagree :)  See below.

Well, I was talking about the proposal you actually made, as opposed to your second proposal made ten hours after my response. :)

I agree that your second proposal solves the obvious inlining problems with your first proposal.

John.