Consider refactoring the x86 hwintrinsic flags

[tannergooding]

Many of the x86 Hardware Intrinsic flags have negative naming conventions, such as: NoContainment, NoJumpTableIMM, and NoRMWSemantics.

We should consider refactoring these into the positive case so that the resulting code is easier to read.

Having helper functions (https://github.com/dotnet/coreclr/issues/16594) may be another way to keep the code more readable without also having to reverse the flags to match the common case (positive), rather than the uncommon case (negative).

category:implementation
theme:hardware-intrinsics
skill-level:intermediate
cost:small

[tannergooding]

CC. @CarolEidt, @fiigii

[fiigii]

NoContainment, NoJumpTableIMM, and NoCodegen is fine, just a few intrinsics need them.

[fiigii]

When we design a flag, I think that should be used as less as possible.

[fiigii]

@tannergooding You have exposed certain convenient functions for these flags, shall we close this?

[tannergooding]

I think @CarolEidt was the one who had remaining feedback on the flags having "negative naming" which made reading them in source code confusing.

[fiigii]

having "negative naming" which made reading them in source code confusing.

Yes, and the convenient functions already help a lot.

[tannergooding]

Right, I don't disagree. This was left open due to the listed preference that the flags still be named "positively" as well: dotnet/coreclr#18255 (comment)

I'll let @CarolEidt close if she thinks that we don't need to rename the root flags given that we have the positively named helper functions now.

[CarolEidt]

When we design a flag, I think that should be used as less as possible.

If a flag must be checked, it doesn't generally matter perf-wise whether you are checking to see if it is set or unset, and I reiterate that negative flags are undesirable. If we must have the flags as-is, we should strive to rename them, e.g. NoContainment becomes RegOperandsOnly.

[fiigii]

If a flag must be checked, it doesn't generally matter perf-wise whether you are checking to see if it is set or unset, and I reiterate that negative flags are undesirable.

From the perf perspective, YES. However, I meant that "used as less as possible" can make the code more maintainable. For example, if a flag is required by 99% intrinsic, it means the other 1% is special and we just need to care the 1%, rather than exploding the concerns to other "normal" ones.

[fiigii]

rather than exploding the concerns to other "normal" ones.

That helps when we add a new intrinsic into the table. We just need to consider what features the new one has, instead of what features that other ones have but the new one not.