Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

/azp run runtime-coreclr outerloop, runtime-coreclr libraries-jitstress

@BruceForstall or @jakobbotsch can you please take a look? should unblock outerloop or anyone else @dotnet/jit-contrib

small diff: https://dev.azure.com/dnceng-public/public/_build/results?buildId=410576&view=ms.vss-build-web.run-extensions-tab (where we know emit a small/different 64bit constant for bt test)

Why are there 0-sized diffs with no textual JitDisasm diff? Can you check some of those cases?

Why are there 0-sized diffs with no textual JitDisasm diff? Can you check some of those cases?

The optimization converts series of x == cns1 || x == cns2 || ... into GT_SWITCH which may be converted to a bt test by an unrelated phase, e.g.: https://godbolt.org/z/87G37YPfT

the bug is basically that the bitmap vector (that 64bit constant bt works with) could become different (and be less than 0xD11FAB1E) so diff (depending on value) may be still the same in terms of size.

Why are there 0-sized diffs with no textual JitDisasm diff? Can you check some of those cases?

the bug is basically that the bitmap vector (that 64bit constant bt works with) could become different (and be less than 0xD11FAB1E) so diff (depending on value) may be still the same in terms of size.

You mean the constant would be different but would still display as 0xD1FFAB1E in both the base and diff?

Is this a case where we JitDump 0xD1FFAB1E but shouldn't? (i.e., it's not a pointer that we would expect to vary between compilations, so why don't we just output the actual constant? Maybe we can't tell if it's a pointer or not at the point of output?)

Since this fixes widespread pipeline failures, I'm going to merge it.