Vector128.CopyTo discards R2R

[EgorBo]

Context #120352 (comment)

The following code-snippet when published with R2R, e.g.:

dotnet publish -f net10.0 -r win-x64 --sc -p:PublishReadyToRun=true

using System.Runtime.Intrinsics;

Test();

static ushort[] Test()
{
    ushort[] numbers = new ushort[8];
    Vector128<ushort>.Zero.CopyTo(numbers);
    return numbers;
}

... has to JIT compile Test() with Tier0, although, it clearly is expected to be prejitted.

JitDump

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[EgorBo]

Info: Method `[ConsoleApp20]Program.<<Main>$>g__Test|0_0()` was not compiled because `Abi unstable type [S.P.CoreLib]System.Runtime.Intrinsics.Vector128`1<uint16> calling [S.P.CoreLib]System.Runtime.Intrinsics.Vector128.CopyTo<uint16>(Vector128`1<uint16>,uint16[])` requires runtime JIT

[EgorBo]

It's not clear to me why it's not inlined.

CheckCanInline: fetching method info for inline candidate CopyTo -- context 40000000004200D0
Method context: System.Runtime.Intrinsics.Vector128:CopyTo[ushort](System.Runtime.Intrinsics.Vector128`1[ushort],ushort[])
INLINER: during 'impMarkInlineCandidate' result 'failed this callee' reason 'cannot get method info' for 'Program:<<Main>$>g__Test|0_0():ushort[]' calling 'System.Runtime.Intrinsics.Vector128:CopyTo[ushort](System.Runtime.Intrinsics.Vector128`1[ushort],ushort[])'

INLINER: Marking System.Runtime.Intrinsics.Vector128:CopyTo[ushort](System.Runtime.Intrinsics.Vector128`1[ushort],ushort[]) as NOINLINE (observation cannot get method info)
INLINER: during 'impMarkInlineCandidate' result 'failed this callee' reason 'cannot get method info'

[tannergooding]

Reposting from Discord

hmmm
https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCompilerContext.cs#L68

we say that only Arm64 respects the vector type ABI, but that's not entirely true

we know its incorrect for interop
but managed to managed is fine, and we can track if such a break was made

likewise on say Windows or Unix, we know the places it is correct vs incorrect
and should probably be more explicit about that

for example, it's really only "incorrect" for vector returns on Windows
parameters are correct for the default convention

but until we fix that, which could be years, we could just have some "isa" bit (effectively) to track a method where that break occurs
so we aren't pessimizing

[EgorBo]

@jkotas @tannergooding so can we just remove that "is arm64" condition for now given that, I believe, we don't have any ABI support for these types anyway today?

[tannergooding]

I'd defer to @jkotas here. But I think we can just generally say that vector types are "stable in managed" for the time being (they are blocked for the purposes of interop today).

When we eventually update the handling for other platforms, which could be this release or could be many releases in the future, then I think it would be fine to take a R2R major bump at that time. I think the same really applies to Vector<T> as well, where we should already be tracking the "size" and throwing away the image on mismatch.

That should ensure that R2R isn't needlessly pessimized today and still allows us to update it to better match the ABI requirements or to add other calling convention support (vectorcall) in the future if/when we get around to it.