<div class="gmail_quote"><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>The following pseudo-IR tries to demonstrate the validity of assignments:</div><div><br></div><div>main:</div><div> </div><div> %a = no_fail_instruction</div><div><br></div><div>test: unwind to lpad</div>
<div><br></div><div> %r = possible_failing_comparison %a, 0</div><div><br></div><div> br %r == 0, label true_block, label false_block</div><div><br></div><div>true_block: unwind to lpad</div><div><br></div><div><div> %c = no_fail_instruction</div>
</div><div><br></div><div><div> %d = potentially_failing_instruction %c</div></div><div><br></div><div> br label either_block</div><div><br></div><div>false_block: unwind to lpad</div><div><br></div><div><div><div> %e = no_fail_instruction</div>
</div><div><br></div><div><div> %f = potentially_failing_instruction %e</div></div></div><div><br></div><div><div> br label either_block</div></div><div><br></div><div>either_block: unwind to lpad</div><div><br></div><div>
%g = phi label true_block %d, false_block %f</div><div><br></div><div><div><div><div> %h = no_fail_instruction %g</div></div><div><br></div><div><div> %i = potentially_failing_instruction %h</div></div></div><div><br>
</div><div> ret %i</div><div><br></div><div>lpad: ; only %a is valid in this landing pad</div><div> cleanup a%</div><div> ret -1</div></div><div><br></div><div>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.</div>
<div><br></div><div>--Nathan</div><div><br></div><div>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.</div><div><br></div></div>