Guard a use of a possibly-uninitialized BitSet.

[pgavlin]

Part of the range check optimization pass was not checking to ensure that a bitset
was initialized before attempting to access it. This was causing one of the new
tests for Vector.Narrow to fail with an AV.

[pgavlin]

@JosephTremoulet @briansull @dotnet/jit-contrib PTAL.

See #9835 for an example of the test failure.

[pgavlin]

@dotnet-bot test Windows_NT x86 corefx_baseline
@dotnet-bot test Ubuntu x64 corefx_baseline
@dotnet-bot test Windows_NT x64 corefx_baseline

[pgavlin]

cc @mellinoe

[JosephTremoulet]

Is it uninitialized because the block is unreachable? It's too bad we spend time trying to compute ranges for unreachable code, but I see the same guard around other calls to MergeEdgeAssertions, so LGTM.

[pgavlin]

Is it uninitialized because the block is unreachable? It's too bad we spend time trying to compute ranges for unreachable code, but I see the same guard around other calls to MergeEdgeAssertions, so LGTM.

I am not sure why it is initialized. I inferred from the other guards that this was an expected case and copy/pasted :/

At some point it would be good to understand why this is happening, but for the moment I'd simply like to unblock our CoreFX testing.

[mikedn]

I am not sure why it is initialized. I inferred from the other guards that this was an expected case and copy/pasted :/

Eh, I keep running into assertion prop weirdness, maybe I'll run into this too :)