Treat BitConverter.IsLittleEndian as an intrinsic

[mikedn]

Fixes #9701

[stephentoub]

This could of course be changed again, but currently the BitConverter that's used by all code outside of corelib is the one defined in CoreFx:
https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Extensions/src/System/BitConverter.cs
in System.Runtime.Extensions.dll. Will this change treat its IsLittleEndian as an intrinsic? Looks like it's specific to the one in mscorlib.

[mikedn]

@stephentoub See the discussion at the end of #9701 and #9788

[stephentoub]

I see, thanks.

[jkotas]

@jashook @prajwal-aithal @sjsinju Linux ARM Emulator builds are failing with:

ERROR: Unable to find project for artifact copy: dotnet_corefx/master/linuxarmemulator_softfp_cross_debug

Could you please take a look?

[hqueue]

@jkotas It's because corefx CI change(dotnet/corefx#16378) has been merged. It can be fixed after #9445 is merged.

[hqueue]

@jkotas I made a quick fix for arm CI break #9797 from #9445.

[hqueue]

@dotnet-bot test Linux ARM Emulator Cross Release Build
@dotnet-bot test Linux ARM Emulator Cross Debug Build

[jkotas]

@dotnet/jit-contrib Could you please take a look?

[pgavlin]

LGTM

[AndyAyersMS]

Do we have a writeup anywhere on what changes should require jit GUID changes?

Adding a new jit intrinsic could generally fall in the "does not require" camp since an older release jit will fail to recognize the new intrinsics and will generate a call instead, but it looks like older debug/checked jits will assert.

[mikedn]

an older release jit will fail to recognize the new intrinsics and will generate a call instead

But how would an older jit end up being used with a new runtime?

[AndyAyersMS]

To be clear: using a mismatched jit/runtime is not an officially supported scenario.

However we do this sort of thing somewhat often during development and bug triage, when making A/B comparisons of jit behavior, or bisecting to track down the origin of bugs.

For instance say somebody reports a bug in the CurrentCLR build -- if we suspect it is a jit regression it is often helpful to quickly pin down when and where the bug was introduced, say to revert a particular change (such things can even be automated). Doing this with the whole CoreCLR package can be awkward or even impossible, if non-jit aspects have changed; the scenario may not even build/run on older runtimes. But the jit/runtime interface typically changes more slowly, so it is often feasible to bisect by just varying jits -- and the GUID changes are one way to mark the plausible ranges over where this can work. So while bisecting, we'swap in a succession of older jits into the newer runtime, and typically these are checked jit builds so we have the full benefit of dumping and internal asserts and diagnostics.