Computing this property within the existing walk ensures that the cost is linear with the size of the block. If we did this from within isGuaranteedToExecute, it would be quadratic without some very fancy caching.
This allows us to reliably catch a hoistable instruction within a header which may throw at some point *after* our hoistable instruction. It doesn't do anything for non-header cases, but given how common single block loops are, this seems very worthwhile.
(The rest of this is not part of the commit message, just recording ideas.)
Given this, we could expand in a couple of directions:
- special case a guard which is known not to be taken on the first iteration of the loop
- support hoisting of guards themselves if we compute an extra IsPrefixReadOnly property as we go.
- I'm seriously considering keeping around the set of loop blocks with implicit control flow in LoopSafetyInfo. Doing so would let us apply a variation of the exit logic combined with this prefix property to handle non-header cases as well.
Here we create some instructions. I think all of them are fine, but doesn't it make sense to assert that each of them transfers execution to successor? Just in case this logic ever changes.