@tannergooding are +100 LOC of if-defs worth it? My personal experience that if-defs make code harder to read 🙁

@EgorBo, that's what the PR is for. It's here to measure the TP impact difference.

Based on what we're seeing for the PR adding TYP_SIMD64, it may be decently "significant" (0.05 - 0.15% or so).

Instead of using TARGET_XARCH, would it be possible to introduce a new feature define (FEATURE_SIMD32?) so it's easy to spot which paths are ifdef'd out because they're part of this feature that are currently xarch only as compared to the ifdefs for parts of the code that are always going to be ifdef'd for TARGET_XARCH?

I don't think it's worth doing so. That's just going to mean we also need FEATURE_SIMD64 and there are no other target architectures out there at the moment which support either features.

Other architectures have instead been introducing "variable width" vectors (e.g. ARM SVE, or what RISC-V has) and the general TYP_SIMD32 support wouldn't apply there either.

If we do end up having to change it in the future, we could look at pulling it out then (and it's relatively simple to do so since it is just finding the few places TYP_SIMD32 is handled.

Yep, this represents a -0.09 to -0.19% TP improvement for Arm64. It is 100% worth the additional #ifdefs

https://dev.azure.com/dnceng-public/public/_build/results?buildId=183840&view=ms.vss-build-web.run-extensions-tab

CC. @dotnet/jit-contrib

Bit less of an improvement with #82616 having been merged (it's -0.01% to -0.06%), but its going to effectively be double that with the TYP_SIMD64 addition in the other PR so still an altogether thing we want to take.