[interp] Ensure that all intrinsics are compiled with R2R in shipping R2R + interpreter configurations

[kg]

As pointed out by @jkotas in the #117727 (comment) thread on PR #117727, if we bounce between running jitted/compiled code for intrinsics and interpreting them, this will produce inconsistent IsSupported/IsHardwareAccelerated return values and as a result inconsistent application behavior or crashes.

The most likely shipping configuration will be R2R + interpreter, so we need to make sure that in this configuration we R2R-compile every intrinsic that might possibly get used, so the interpreter can invoke the R2R'd code for all intrinsics where possible.

[dotnet-policy-service]

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

[jkoritzinsky]

@kg I've done the work in crossgen2 to enable the intrinsics we want to enable (architecture-specific instructions). After chatting with @tannergooding and @agocke, we felt that the not-"must-expand" platform-agnostic hardware intrinsics should be left to their fallbacks (and IsHardwareAccelerated for such types left to return false when interpreted) for the interpreter as the cost to transition between R2R and interpreter is more than the benefit of the accelerated implementations.

In which case, is there any more work to do here? Do we want to add some sort of validation in the interpreter when compiling a method that calls a hardware intrinsic?

cc: @kotlarmilos @davidnguyen-tech as #120047 is related

[kg]

After chatting with @tannergooding and @agocke, we felt that the not-"must-expand" platform-agnostic hardware intrinsics should be left to their fallbacks (and IsHardwareAccelerated for such types left to return false when interpreted) for the interpreter as the cost to transition between R2R and interpreter is more than the benefit of the accelerated implementations.

The concern here is correctness not performance, isn't it? Does this leave us in a state where IsHardwareAccelerated can be observed with different values depending on whether the current method is interpreted or not?

In which case, is there any more work to do here? Do we want to add some sort of validation in the interpreter when compiling a method that calls a hardware intrinsic?

That's a good question. I think it's better answered by @davidwrighton or @janvorli .

[davidwrighton]

I'm pretty sure we need to actually make the intrinsics work in the interpreter for correctness reasons.