More Code Cleanup for EH WriteThru by CarolEidt · Pull Request #1180 · dotnet/runtime (original) (raw)

The comment is not entirely correct. If we don't have a predecessor, then we will add DummyDefs to avoid the default behavior that everything's on the stack (except for the case of the first block or blocks with incoming EH flow). However, this adds unnecessary compile-time cost and may actually result in more mismatches at the boundaries. So we're better off to simply use the variable locations from the previous block.

I have encountered non-empty non-EH blocks with no predecessor that resulted from optimizations that deleted the branch to it, but not all the instructions - I believe it is the case that they are marked in such a way that they can't be deleted.

AFAIK all handlers do not have predecessors, are there exceptions?

A finally block, for example, is considered to have an incoming EH boundary (all vars must be on the stack), but it will have predecessors.