There's a case that was missing in this optimization. We install invalidation
points on a block's dominance frontiers when the block contains som
invalidation instructions. However, if a block is an entry to exception
handler, state is always invalidated. This should be done
since exception handler may recover and proceed with some code that
follows try/catch block. Without this change code after try/catch inherits
state of `try` block, which is invalid, since `catch` is another
source from where we can get there. We can't rely on regular instruction
analysis in `catch` blocks, since we get into `catch` from an unpredictable
point.
Although initial purpose of this comment was null check,
it took much time to complete it and it caused many unrelated changes.
Besides just implementing null check in quite naive fashion
(I could not use the trick with memory protection, since I have to
maintain shadow stack, and support WebAssembly), I had to optimize
things. I relied on my existing nullness analysis to eliminate
as much null checks as possible. However, the whole nullness analysis
was wrong. After some thoughts I came up with solution very
close to range analysis, which required me to introduce extension
to IR sometimes called e-SSA form with so called sigma nodes.
Also, I found some bugs in few different places (by the time write this
message I could only remember escape analysis/scalar replacement and
after-inlining devirtualization) and fixed them.
