Move GenTreeVecCon and GenTreeMskCon under the respective FEATURE_* defines

[tannergooding]

Follow up from #104875

[dotnet-policy-service]

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

[tannergooding]

This represents just general cleanup and can be delayed until .NET 10

[tannergooding]

CC. @kunalspathak, this should be ready for review.

Just represents the general cleanup we had talked about around the constants and ensuring they're under the right #define

[jakobbotsch]

Don't our most important targets have these defined? Is there a tangible benefit from doing something like this? From what I see it's just introducing a lot of ifdef soup that makes the code harder to read. I would personally like if we moved toward fewer conditionally defined nodes/opers rather than more of them, except if there are some really tangible benefits.

cc @dotnet/jit-contrib

[tannergooding]

Don't our most important targets have these defined?

Yes, at least for FEATURE_SIMD. For our official targets I believe just UNIX_X86 and ARM32 don't support it. There's more that don't when you factor in community targets.

I would personally like if we moved toward fewer conditionally defined nodes/opers rather than more of them, except if there are some really tangible benefits.

I don't disagree.

SIMD is really a fundamental part of the ABI. HW_INTRINSICS (and MASKED_HW_INTRINSICS) are then built on top of the SIMD feature, and its something that's so integral to perf in the BCL that not having it is a huge detriment to the user experience.

We somewhat have the split due to historical reasons and it would be nice if we merged them together into a single feature, but it won't remove most of the ifdef soup while we have targets without SIMD support.

With this PR, we're not really introducing any new ifdef soup and it actually simplifies it in other cases. The places it remains soupy are mainly the places we have to do different things for SIMD vs no SIMD.

[kunalspathak]

LGTM

[tannergooding]

@jakobbotsch do you have any other input on this one?

My preference would be to take this, given it makes our build given existing defines more correct. Then to separately look at (and come to a shared decision with the JIT team) as to how we want to simplify it, if at all.

There's a couple of older issues that allude to such a cleanup: #9473 and #11701, but we've never actually determined what should actually be done. Such a cleanup (when/if it happens) will likely be quite a bit more involved

[jakobbotsch]

If your preference is to take it I am ok with it, but at some point I might experiment with the clean up that goes in the opposite direction and makes all node types and node classes unconditionally defined everywhere (just not appearing for some targets).