Provide x86 CPUID related information

[damageboy]

Proposal

Rationale

There's a breadth of information available through the CPUID instruction.
Most of this information is not available today from C#, with the exception of information like
support for specific families of HW Intrinsics which is surfaced through the IsSupported JIT time constant/property in each respective group of intrinsics.

I've lightly touched on this in a different issue, but I think this deserves an issue of its own in light with the specific needs that I have in mind.

To name a few types of information that are not currently provided:

• Specific CPU Model (Kaby Lake / Skylake etc.)
• Manufacturer
• Various key HW info like:
  • Layout of the caches:
    • cache line sizes
    • levels
    • associativity
    • TLB levels, sizes
  • Topology of the system (NUMA Nodes, physical/logical mapping) and it's mapping to CPU affinity masks

This information could be used to select proper code paths or pre-allocate data structures with sizes that relate to the actual HW at hand.

Proposed API

namespace System.Runtime.Intrinsics.X86
{
    public class X86Base
    {
        public static bool IsSupported { get; }

        public static (int Eax, int Ebx, int Ecx, int Edx) CpuId(int functionId, int subFunctionId = 0);
    }
}

Alternatives and Other Considerations

Given that Value Tuples are currently considered AVOID, an alternative is to match the C++ signature of public static void CpuId(int* cpuInfo, int functionId) and public static void CpuId(int* cpuInfo, int functionid, int subFunctionId)

CPUID is not technically a baseline instruction. It requires its own check using the ID bit of the EFLAGS register. However, only CPUs prior to the 486SL (released in 1992) won't have this feature available. In order to minimize the number of ISAs that only contain 1-2 methods (like Lzcnt), it is proposed to simply consider this part of X86Base rather than it be in its own CpuId class.

It is also important to make note that other, cross-platform/architecture methods of obtaining such information are available today, namely the hwloc native library that can provide most if not all of this and beyond through a normalized native API, and ultimately give us this view of our own systems (screenshot of lstopo generated output, part of the hwloc library):

For reference, here's a sample of cpuid generated to show what's up for discussion.

Relevant issues:
https://github.com/dotnet/corefx/issues/22790
https://github.com/dotnet/coreclr/issues/14388

[tannergooding]

I had thought a bit about this previously and believe an appropriate API would look something like:

// casing of the name here is weird but follows the .NET naming guidelines
public abstract class CpuId
{
    internal CpuId() { }

    // We can't use CpuId for the method as it conflicts with the class
    // name. Some other name may be better but `Query` seems to fit

    // Signature matches the C++ convention for __cpuid and __cpuidex
    // we could also return a tuple or an explicitly typed struct and
    // could reorder the parameters so the "out buffer" is last

    // Using `uint` rather than `int` may also be better for C# since most
    // bit manipulations should be unsigned and there are negative "max values"

    public static void QueryCpu(int* cpuInfo, int functionId);
    public static void QueryCpu(int* cpuInfo, int functionId, int subFunctionId);
}

We could then additionally expose helper properties for certain key information. For example:

public static bool IsAuthenticAMD { get; }
public static bool IsGenuineIntel { get; }

public static uint MaxFunctionId { get; }

// etc

[damageboy]

I think this would be a great sort of addition.

Some properties are surfaced all the way as static native types, treated as JIT time constants.
I think that the "minimum" set (in my opinion, that is, of course) would have to include some more data about cache layout, processor layout, and topology, while leaving the really nutty stuff to be queried through the QueryCpu() methods you propose.

I'm assuming you meant for the function to either accept (out uint eax, out uint ebx, out uint ecx, out uint edx) or return them as a value tuple (but value tuples are verboten in CoreFX, IIRC)... right?

I even hacked up something like this a long long time ago :), back when I was popping the stack pointer and re-writing the call-site to add intrinsics "dynamically" (Don't ask):
https://github.com/damageboy/ReJit/blob/master/ReJIT/CPUID.cs

The one "big" thing that would be still "missing" is that this would not allow for usage inside
existing/future attributes controlling layout/alignment, since, well, it isn't a compile time constant...

I guess that is more of an issue at the CLR level where certain things have to be constants at compile-time even though in theory they could be expressed as constants at JIT time (Had that notion of late-bound constant was acceptable/supported).

[tannergooding]

(but value tuples are verboten in CoreFX, IIRC)

I believe we resolved the naming issues that prevented them from being used and now merely recommend against their use.

@CarolEidt could probably comment on the best way to expose the signature that can also work efficiently with the register allocator. Namely, cpuid returns its result in rax, rbx, rcx, and rdx. C++ takes a int cpuInfo[4] (which is effectively just a int* that is has space for 4 elements), so we need to return 4 results either via some stack allocated space or a specialized struct/value tuple.

[CarolEidt]

A struct/value tuple with 4 elements would be quite problematic to do efficiently (given current JIT capabilities) if it were an actual call. As it is, since intrinsics are expanded early in the JIT, it's just a bit less problematic. The remaining issue is that we'd really like to express this as an instruction that defines multiple (register) values, and the register allocator (indeed, the JIT more broadly) currently doesn't handle that really well (even multi-register returns and longs on arm32 are supported as special cases). That's a recurring issue, though, that we probably should just address. It will probably require additional register allocator work to handle a case where not only does it define multiple registers, but they are fixed. Again, doable but probably a bit tricky.

[jkotas]

I do not think CPUID instruction needs to be handled as HW intrinsic by the JIT. It can be a regular call to C or assembly helper that the JIT knows nothing about. CPUID is expensive. You want to call it once and cache the result.

[damageboy]

I think @jkotas is right.
CPUID is not the sort of thing you don't need to optimize in general, but rather cache.

The only reason to even consider CPUID as an full-blown intrinsic would be if for some reason .NET/CoreCLR programmers would benefit somehow by CPUID's only other saving grace: the fact that it is a serializing instruction, and the easiest one to issue userspace.

Quoting Intel's SDM Volume 3, section 8.3:

Non-privileged serializing instructions — CPUID, IRET, and RSM.
When the processor serializes instruction execution, it ensures that all pending memory transactions are completed (including writes stored in its store buffer) before it executes the next instruction. Nothing can pass a serializing instruction and a serializing instruction cannot pass any other instruction (read, write, instruction fetch, or I/O). For example, CPUID can be executed at any privilege level to serialize instruction execution with no effect on program flow, except that the EAX, EBX, ECX, and EDX registers are modified.

I might be unimaginative, but I'm having a hard time coming up for a reason to call this from userspace/CoreCLR.

Perhaps other people can think of a real use case for having this as an intrinsic for its serializing property...

[tannergooding]

It can be a regular call to C or assembly helper that the JIT knows nothing about

Are you indicating that a CpuId API, if exposed, would be more akin to an InternalCall that invokes __cpuid and __cpuidex?

You want to call it once and cache the result.

Right and there are certain key CPUID properties that it would be beneficial to be more broadly exposed and which are x86 specific. For example, IsGenuineIntel and IsAuthenticAMD checks which would be used in conjunction with other hardware intrinsics.

Will the existing JIT constant folding logic around static readonly fields allow these cases to work?

There are also certain hardware properties which would be beneficial to more broadly expose but which may also be beneficial for other platforms (such as cache line sizes) and I think we have an issue tracking those.

[jkotas]

Are you indicating that a CpuId API, if exposed, would be more akin to an InternalCall that invokes __cpuid and __cpuidex?

Right.

Will the existing JIT constant folding logic around static readonly fields allow these cases to work?

Yes, with tirered JITing.

[AndyAyersMS]

FWIW the native compiler has to play some tricks to safely emit cpuid for x86, since it kills so many registers. Would be nice if we didn't have to propagate those tricks to the jit.