We should ensure this doesn't impact inlining.

The IL is going to be larger as a result of the call and not every lowlevel API is currently Intrinsic and so may not "boost inlining" to account for the increase in IL size.

I believe MemoryMarshal.GetReference was recently updated to be Intrinsic and so should, but it would be good to double check that codegen isn't negatively impacted anywhere.

I think both old and new are under "always inline" limit so it's fine

Added AggressiveInlining just to be sure.

@tannergooding / @EgorBo, do we want the extra attribute?

I believe MemoryMarshal.GetReference was recently updated to be Intrinsic and so should, but it would be good to double check that codegen isn't negatively impacted anywhere.

There is no IntrinsicAttribute on MemoryMarshal.GetReference.

do we want the extra attribute?

@stephentoub, RyuJIT currently defines ALWAYS_INLINE_SIZE = 16 and so any method with a number of IL bytes less than this should implicitly be treated this way. Other runtimes may have their own differing limits and, with MethodImplOptions being one of the metadata special attributes, there is no real harm in providing it since it doesn't impact IL metadata size. It effectively just ensures the JIT gives it the same multiplier.

That being said, SharpLab shows that GetDigitsPointer is 17 bytes of IL:

        IL_0000: ldarg.0
        IL_0001: ldfld valuetype [System.Runtime]System.Span`1<uint8> C::Digits
        IL_0006: call !!0& [System.Memory]System.Runtime.InteropServices.MemoryMarshal::GetReference<uint8>(valuetype [System.Runtime]System.Span`1<!!0>)
        IL_000b: call void* [System.Runtime]System.Runtime.CompilerServices.Unsafe::AsPointer<uint8>(!!0&)
        IL_0010: ret

Because of this, it is not guaranteed to be inlined even though what we're doing compiles down to a field read, so it would be directly beneficial to annotate it here.