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