Repository navigation
Vector128.CopyTo discards R2R #120367
Description
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.
Activity
dotnet-policy-service commentedon Oct 3, 2025
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.
EgorBo commentedon Oct 3, 2025
EgorBo commentedon Oct 3, 2025
It's not clear to me why it's not inlined.
tannergooding commentedon Oct 3, 2025
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 commentedon Oct 15, 2025
@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 commentedon Oct 15, 2025
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.
jkotas commentedon Oct 15, 2025
Yes, as long as it won't result in JIT vs. R2R/AOT behavior differences for interop. If somebody uses these types for interop and we throw not supported exception with JIT, we should continue to throw after the app is published with R2R/AOT.
Mark the special ABI primitive types as having stable layout (dotnet#…