Don't return 0 from getMaxVectorByteLength when intrinsics are disabled

[tannergooding]

This works around the issues tracked by:

• Test failure JIT/Stress/ABI/pinvokes_do/pinvokes_do #87388
• Test failure JIT/Directed/arglist/vararg_TargetWindows/vararg_TargetWindows #87389
• Test failure: JIT/Directed/StructABI/MisSizedStructs_ArmArch/MisSizedStructs_ArmArch.dll #87408
• Test failure: JIT/Regression/JitBlue/Runtime_65937/Runtime_65937/Runtime_65937.dll #87409

These represent existing issues that were exposed by #85551 as it started having getMaxVectorByteLength return 0 if the relevant ISAs were disabled and therefore caused the JIT to go down its fallback paths (i.e. the path that might be executed on x86 Unix or Arm32).

The proper fixes for these are likely going to be a bit more involved and may require distinguishing what exists as required ABI handling (and therefore must use SIMD) vs what only exists as a perf optimization and therefore needs its fallback path to operate correctly even if the ISA is not available.

[ghost]

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

Issue Details

---

This works around the issues tracked by:

• Test failure JIT/Stress/ABI/pinvokes_do/pinvokes_do #87388
• Test failure JIT/Directed/arglist/vararg_TargetWindows/vararg_TargetWindows #87389
• Test failure: JIT/Directed/StructABI/MisSizedStructs_ArmArch/MisSizedStructs_ArmArch.dll #87408
• Test failure: JIT/Regression/JitBlue/Runtime_65937/Runtime_65937/Runtime_65937.dll #87409

These represent existing issues that were exposed by #85551 as it started having getMaxVectorByteLength return 0 if the relevant ISAs were disabled and therefore caused the JIT to go down its fallback paths (i.e. the path that might be executed on x86 Unix or Arm32).

The proper fixes for these are likely going to be a bit more involved and may require distinguishing what exists as required ABI handling (and therefore must use SIMD) vs what only exists as a perf optimization and therefore needs its fallback path to operate correctly even if the ISA is not available.

Author:	tannergooding
Assignees:	tannergooding
Labels:	area-CodeGen-coreclr
Milestone:	-

[tannergooding]

/azp run runtime-coreclr jitstress-isas-x86, runtime-coreclr jitstress-isas-arm

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[tannergooding]

CC. @dotnet/jit-contrib. This resolves all the jitstress-isas-x86 failures. There remain some unrelated jitstress-isas-arm failures.

As per the top post, this is namely a workaround and puts us back to our previous behavior. There are some underlying pre-existing issues that would be good to resolve longer term.

[EgorBo]

I assume it happens because we have all the SIMD stuff that can be disabled by EnableXXX/HWIntrinsics, but also, we have direct SIMD usages where we just assume that the baseline simd is always around?

[tannergooding]

I assume it happens because we have all the SIMD stuff that can be disabled by EnableXXX/HWIntrinsics, but also, we have direct SIMD usages where we just assume that the baseline simd is always around

I believe part of it is that, yes. But I think more-so there is ABI handling that is split between the two today and it should instead live exclusively on one or the other.