[LLVMdev] RFC: Exception Handling Proposal Revised

[Frits van Bommel]

On Wed, Dec 1, 2010 at 12:40 PM, Renato Golin <rengolin at systemcall.org> wrote:
> On 1 December 2010 11:11, Frits van Bommel <fvbommel at gmail.com> wrote:
>> If there were also catches, they'd probably need to explicitly execute
>> the finally code (or if they again throw, have their unwind edges
>> point to a dispatch with a catch-all to the finally code).
>
> The problem is that, the code has to be run regardless of throwing or
> not, but the exit of the finally block change depending on its
> predecessor...
>
> So either you have two identical blocks (like the clean-up code) or

IIRC that's how LDC deals with it (D has 'finally' blocks).

> you have a special way of defining the exit condition based on the
> predecessor (like PHI nodes for EH, which is horrible!).

You could do this too. I don't think there's any need for a special
way to define it though. Just use a switch on a phi. If you use
"unwind resume" for rethrowing you may still need to duplicate the
code once per EH region though, to make sure it's dominated by the
landing pad.

Jump threading should be able to clean this up just fine by
duplicating the finally code if it considers doing so profitable
enough (i.e. if the duplicated code is small enough). And if not,
apparently not duplicating was the right thing to do :).

You could even use an indirect branch on a phi of blockaddresses, but
I wouldn't recommend it. And not just because jump threading can't
handle it. indirectbr is gross, and should probably be avoided unless
the program you're compiling explicitly asks for it (with computed
gotos).