llvm dev - Dec 2010 - [LLVMdev] Inlining and exception handling in LLVM and GCC

On 8 December 2010 18:45, Devang Patel <dpatel at apple.com>
wrote:
> I do not know EH or details of these proposals. But do not forget, basic
blocks are merged/split/deleted, instructions are
added/removed/moved/copied/replaced.
Indeed. Having the information in the invoke kinda alleviates this
problem, but removing the invoke syntax will bring that back.

One way to merge two basic blocks is to split into several smaller
basic blocks with same properties and then branch to and from that new
sub-block instead of actually moving the instructions inside the
merged block.

I don't know the effects of block fragmentation in LLVM, but that
would definitely increase it. But having EH info in every instruction
is also too much... :/

cheers,
--renato

I like the idea of the landing pad being associated with the basic block. It
seems to me that the branch to the landing pad should be viewed
as occurring at the beginning of the "earliest" block to branch to
that
landing pad. No assignments that occur in any block that unwinds to a
particular landing pad are valid in that landing pad or
any subsequent blocks. Other than that, standard SSA rules apply.

With this view, it would be legal to split or  combine consecutive blocks
linked to the same landing pad. It would also be legal to move instructions
around within a control flow of blocks linked to the same block. To go any
further would require that a pass make changes to the landing pads to
preserve the validity of relevant assignments.

It would only be legal to specify a landing pad block as the target of an
unwind edge. If cleanups need to be chained, they cannot be in the landing
pad directly, and must instead be branched to from the landing
pad. Given this important distinction it may make sense to make landing pad
blocks special in the IR to facility detecting misuse (both pragmatically
and visually).

The following pseudo-IR tries to demonstrate the validity of assignments:

main:

  %a = no_fail_instruction

test: unwind to lpad

  %r = possible_failing_comparison %a, 0

  br %r == 0, label true_block, label false_block

true_block: unwind to lpad

  %c = no_fail_instruction

  %d = potentially_failing_instruction %c

  br label either_block

false_block: unwind to lpad

  %e = no_fail_instruction

  %f = potentially_failing_instruction %e

  br label either_block

either_block: unwind to lpad

  %g = phi label true_block %d, false_block %f

  %h = no_fail_instruction %g

  %i = potentially_failing_instruction %h

  ret %i

lpad: ; only %a is valid in this landing pad
  cleanup a%
  ret -1

In this sequence, during the normal flow, every thing works as expected.
With the landing pad, dominance is calculated differently and only %a is
valid as it is the only assignment guaranteed to occur before *any* block
that unwinds to the landing pad.

--Nathan

p.s. I apologize if this was the intended behavior all along, I have been
trying to follow this discussion as best as I can.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101208/6340bbfb/attachment.html>

Hi Nathan,
> I like the idea of the landing pad being associated with the basic block.
It
> seems to me that the branch to the landing pad should be viewed as
occurring at
> the beginning of the "earliest" block to branch to that landing
pad. No
> assignments that occur in any block that unwinds to a particular landing
pad are
> valid in that landing pad or any subsequent blocks. Other than that,
standard
> SSA rules apply.
yup - dominance rules of this kind were already discussed in a bunch of emails
earlier.

Ciao,

Duncan.