Expose 64-bit only hardware intrinsic in nested classes

[fiigii]

This PR contribute to https://github.com/dotnet/coreclr/issues/20062

1. Each ISA class may have a nested class named X64 to contain 64-bit only hardware intrinsic. .
2. This PR only moves "intrinsic" into the nested classes, and helper intrinsic will support 32-bit platforms by fallback or JIT in the next steps.

[fiigii]

I only added new APIs in this PR and not remove the old ones to avoid disabling so many tests. After the APIs get reflected back to CoreCLR and implemented in JIT, I will migrate tests to new APIs and remove the old APIs in one shot. That would make the workflow simpler.

[fiigii]

@CarolEidt @tannergooding @eerhardt @terrajobst

[tannergooding]

I think just X64 would be a better name, and would still convey the appropriate meaning.

[fiigii]

Thanks for the suggestions. I am worrying that X64 may be confusing sometimes. We are using X86 to represent all the Intel/AMD platforms, X64 may let users think X86 is for 32-bit only.

[fiigii]

IMO, we should emphasize that X86 covers 32-bit and 64-bit both.

[4creators]

We are using X86 to represent all the Intel/AMD platforms, X64 may let users think X86 is for 32-bit only.

You are right, this could be a problem. How about Arch64Bit?

[4creators]

Or actually ArchX64

[tannergooding]

X64 may let users think X86 is for 32-bit only

I think, given the targeted users for these APIs, any documentation we make available, and the limited scope of the x64 classes, the majority of users will be able to easily figure out that the types in Sse are generally available and the types in Sse.X64 are for 64-bit computers only.

[4creators]

will be able to easily figure out that the types in Sse are generally available and the types in Sse.X64 are for 64-bit computers only.

IMO we do not have to stick to acronyms. Adding short extension to X64 like Only suffix or Arch prefix creates self documenting, easy to understand code.

[eerhardt]

    public static ulong AndNot(ulong left, ulong right) => AndNot(left, right);

Do you want to remove this method? I assume the ulong overload should only exist in the nested X64 class.

---

Refers to: src/System.Private.CoreLib/shared/System/Runtime/Intrinsics/X86/Bmi1.cs:85 in 86d7c37. [](commit_id = 86d7c37, deletion_comment = False)

[fiigii]

Do you want to remove this method? I assume the ulong overload should only exist in the nested X64 class.

@eerhardt I only added new APIs in this PR and not remove the old ones to avoid disabling so many tests. After the APIs get reflected back to CoreCLR and implemented in JIT, I will migrate tests to new APIs and remove the old APIs in one shot. That would make the workflow simpler.

[fiigii]

@dotnet-bot test OSX10.12 x64 Checked Innerloop Build and Test

[fiigii]

@CarolEidt Do you have comments or suggestions for this PR? If it looks good to you, I think it ready to merge.

[fiigii]

Changed the X64 class inheritance, now the hierarchy becomes:

Bmi1.X64 -> Object
Bmi2.X64 -> Object
Lzcnt.X64 -> Object
Popcnt.X64 -> Sse42.X64 -> Sse41.X64 -> Sse2.X64 -> Sse.X64 -> Object

[CarolEidt]

Sorry for being a bit late to the discussion on this.
IMO, the use of x64 could indeed be confusing, as it is used in numerous coreclr contexts as a shorthand for x86-64. I think something like 64Bit would be less ambiguous.

Also, I think that this sort of naming issue should be discussed on the corefx issue (https://github.com/dotnet/coreclr/issues/20062), as it is really an ABI discussion, which IMO is not appropriate for a coreclr PR.

[fiigii]

@CarolEidt Thanks for the comments. I opened a CoreFX issue https://github.com/dotnet/corefx/issues/32721 to discuss this kind of naming issues.

[pentp]

@CarolEidt

IMO, the use of x64 could indeed be confusing, as it is used in numerous coreclr contexts as a shorthand for x86-64. I think something like 64Bit would be less ambiguous.

But that is the exact intended meaning here (e.g., Intrinsics.X86.Bmi1.X64 = BMI on x86-64), these intrinsics are not applicable to any other 64-bit platform.
To me X64 looks concise and clear.

[fiigii]

@dotnet-bot test this please

[fiigii]

Fixed build warnings and comments (platforms->processes).

[fiigii]

CoreFX surface change at dotnet/corefx#33286

[eerhardt]

[tannergooding]

Closing and re-opening to ensure all jobs run (rather than just 7). I doubt this broke anything, but better to be safe than sorry 😄

[fiigii]

@dotnet-bot test this please

[fiigii]

CI gets stuck again 😂

[fiigii]

@dotnet-bot test Ubuntu arm Cross Checked crossgen_comparison Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked no_tiered_compilation_innerloop Build and Test
@dotnet-bot test Ubuntu x64 Checked Innerloop Build and Test

[tannergooding]

test Ubuntu arm Cross Checked Innerloop Build and Test please
test Ubuntu arm Cross Checked crossgen_comparison Build and Test please
test Ubuntu arm Cross Checked no_tiered_compilation_innerloop Build and Test please
test Ubuntu x64 Checked Innerloop Build and Test (Jit - TieredCompilation=0) please
test Ubuntu16.04 arm64 Cross Checked no_tiered_compilation_innerloop Build and Test please
test OSX10.12 x64 Checked Innerloop Build and Test please
test Ubuntu x64 Checked Innerloop Build and Test please
test Ubuntu x64 Formatting please
test Windows_NT x64 Checked Innerloop Build and Test please
test Windows_NT x64 Formatting please

[tannergooding]

Jenkins seems to be working again, so hopefully the jobs retrigger and don't fail

[tannergooding]

Thanks @fiigii