[LLVMdev] RFC: Exception Handling Proposal II

[Bill Wendling]

On Nov 24, 2010, at 5:47 AM, Renato Golin wrote:

>> So the above code would look something like this:
>> 
>> entry:
>>  invoke @f.run() to %bb unwind to %FooCleanup region(1)
>> bb:
>>  invoke @b.run() to %bb2 unwind to %BarCleanup region(1)
>> bb2:
>>  invoke @z.run() to %bb3 unwind to %BazCleanup region(1)
>> ...
>> BazCleanup:
>>  ; do stuff
>>  br %BarCleanup
>> BarCleanup:
>>  ; do stuff
>>  br %FooCleanup
>> FooCleanup:
>>  ; do stuff
>>  br %Dispatch
>> Dispatch:
>>  dispatch region(1) resume %block
>>    catches [ ... ]
>> 
>> and so on.
> 
> I see. The front-end is responsible for knowing that baz, bar and foo
> cleanup area are chained together.
> 
> So, if I got it right, the dispatch area is common for the whole
> function, all final cleanup areas point to the dispatch, and the
> back-end knows which dispatch "instruction" to call based on the
> region number. The dispatch instructions then would encode what type
> of dispatch they were just based on the filters, catches, etc.
> 
That's correct. With the caveat that there can be more than one dispatch area per function and some may be nested.

>> If we remove the invoke instructions, the "unwind to" information then goes onto the basic block itself. E.g.:
>> 
>> bb: unwind to %FooCleanup
>>  call @f1.run()
>>  call @f2.run()
>>  call @f3.run()
>>  call @f4.run()
> 
> In the general case, that simplifies a lot.
> 
> But in this case, if you were constructing the objects as you call
> them (as previous example), you'd have to tell the call to which
> cleanup landing pad you have to go.
> 
> One option is to separate in basic blocks with different cleanup landing pads:
> 
> bb: unwind to %FooCleanup
> call @f1.run()
> br bb1
> bb1: unwind to %BarCleanup
> call @f2.run()
> br bb2
> bb1: unwind to %BazCleanup
> call @f3.run()
> %0 = div i32 7 i32 0  ; this throws in Java and goes to BazCleanup
> br bb3
> bb1: unwind to %Dispatch  ; no cleanup
> call @f4.run()
> br bb4
> 
Yeah, that's the basic idea. As John mentioned, this is an orthogonal change that we need to work out in the future. Chris had the above idea in the notes he wrote. But we will need to determine if it's sufficient or if there's a better solution.

>> I kept it purely from a practical standpoint: it will be easier (and thus quicker) to do it this way. :-) Also, it could be done a bit more incrementally than completely removing the invoke. But I'm not opposed to removing the invoke.
> 
> I hadn't quite got the role of the invoke in your intermediary model,
> now I get it. ;)
> 
> I think we should ultimately treat calls like instructions and not
> mark them in any specific way regarding EH.
> 
I totally agree. :-)

-bw