Current Intrinsic procedure

[deeprobin]

Hi guys, I noticed that the intrinsics are always referred to with a self-calling method.

runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/X86/X86Base.cs

Lines 26 to 35 in 84680bf

	/// <summary>
	/// unsigned char _BitScanForward64 (unsigned __int32* index, unsigned __int64 a)
	/// BSF reg reg/m64
	/// The above native signature does not directly correspond to the managed signature.
	/// </summary>
	/// <remarks>
	/// This method is to remain internal.
	/// Its functionality is exposed in the public <see cref="System.Numerics.BitOperations" /> class.
	/// </remarks>
	internal static ulong BitScanForward(ulong value) => BitScanForward(value);

Of course, I realize that these do not call themselves but are processed by the JIT accordingly.

Nevertheless, I find this semantically a bit strange.
Why is it done this way?

Wouldn't an external method make more sense?
For ex.

[MethodImplAttribute(MethodImplOptions.InternalCall)]
internal extern static ulong BitScanForward(ulong value); 

or maybe in a explicit way

[MethodImplAttribute(MethodImplOptions.Intrinsic)]
internal extern static ulong BitScanForward(ulong value); 

    [Flags]
    public enum MethodImplOptions
    {
        Unmanaged = 0x0004,
        NoInlining = 0x0008,
        ForwardRef = 0x0010,
        Synchronized = 0x0020,
        NoOptimization = 0x0040,
        PreserveSig = 0x0080,
        AggressiveInlining = 0x0100,
        AggressiveOptimization = 0x0200,
-       InternalCall = 0x1000
+       InternalCall = 0x1000,
+       Intrinsic = 0x1337 // (just a dummy number)
    }

/cc @tannergooding

[EgorBo]

As far as I remember it's done just to handle Reflection, so if you (for some reason) decide to call e.g. BitScanForward via reflection - JIT will expand the inner call.

Also it helps with cases where e.g. some SSE intrinsic only works with constant input but user passes a variable - so it will expand that variable into a switch inside the API itself.

Recursion is never expected to happen.

[deeprobin]

I am aware that recursion is never expected.

I'm really more interested in code readability (and that VS doesn't always complain that I cause an endless recursion).

Wouldn't it make sense to implement a change (as mentioned above) and adapt the JIT accordingly, so that in the reflection case this is expanded anyway?

[tannergooding]

Its non-trivial to update the JIT to do all the relevant stuff here. The recursion is the most trivial way to enable it and allows reflection, non-constant inputs, and other forms of indirect execution (including function pointers or delegates) to be used.