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

Reopened now that#102702,#102827, and#102973 has gone in. We should no longer see pessimizations caused from needing constants during import and so we should see fewer diffs overall and ideally be in a position to consider getting this merged and building on it more.

Things are already looking much better than before.

minopts size regressions are expected since it would now require inlining to get the optimized codegen. This is something that needs to be discussed around the overall impact, but I expect its fine since itsT0 code.

fullopts has almost no changes and we are doing the right thing for the most part. There are some more complex methods where we run into limits for the default inlining heuristics given that we no longer get the[Intrinsic] profitability boost. We could solve this by still treating APIs inSystem.Runtime.Intrinsics as[Intrinsic], regardless of whether or not they're annotated. This gives us the profitability boost without needing to also have the implementation in managed.

There is an assert aroundV512.CreateScalar that needs to be looked at and some mono failures, which at a glance looks to be a legitimate bug in Mono.

@MihuBot

One regression is inSystem.Drawing.RectangleF:ToVector4()

-       vmovups  xmm0, xmmword ptr [rdi]+       vmovss   xmm0, dword ptr [rdi]+       vinsertps xmm0, xmm0, dword ptr [rdi+0x04], 16+       vinsertps xmm0, xmm0, dword ptr [rdi+0x08], 32+       vinsertps xmm0, xmm0, dword ptr [rdi+0x0C], 48

This one is because while we havefgMorphCombineSIMDFieldStores, we don't have anfgMorphCombineSIMDFieldLoads instead we only had some logic as part ofNI_Vector4_Create that looked for consecutive field accesses. This one shouldn't be a blocker and can be pretty easily handled in a follow up PR.

There's a small regression inSystem.IO.Hashing.Crc32:UpdateVectorized:

 G_M1352_IG02:        mov      rax, rsi        mov      ecx, edx-       vmovups  xmm0, xmmword ptr [rax]        cmp      ecx, 128        jge      SHORT G_M1352_IG04- ;; size=17 bbWeight=1 PerfScore 5.75+;; size=13 bbWeight=1 PerfScore 1.75 G_M1352_IG03:-       vmovd    xmm1, rdi-       vpxor    xmm0, xmm1, xmm0+       vmovd    xmm0, rdi+       vpxor    xmm0, xmm0, xmmword ptr [rax]        jmp      G_M1352_IG07        align    [0 bytes for IG05]- ;; size=13 bbWeight=0.50 PerfScore 2.17+;; size=13 bbWeight=0.50 PerfScore 3.50 G_M1352_IG04:+       vmovups  xmm0, xmmword ptr [rsi]        vmovups  xmm1, xmmword ptr [rsi+0x10]

Nothing major, just a place where we don't share a load anymore.

In general the JIT ends up needing to create many additionalimpAppendStmt,Inlining Arg,spilled call-like call argument, andInline ldloca(s) first use temp locals. Most of these end up aszero-ref and so there's potential for the JIT to optimize things better around such scenarios to avoid additional or unnecessary overhead (throughput wise).

Most of the corelib regressions are in the xplat APIs that don't have any accelerated implementation today, likeDot<short> (lack of handling for multiply since it would have been fairly complex IR to support). Others are cases likeVector512.OnesComplement which would be fixed if we had it defer toop_OnesComplement rather thanVector256.OnesComplement (an easy fix in a follow up PR).

All in all, I think we are in a position where taking this is feasible and it doesn't look to regress any meaningful scenarios, only the already unaccelerated edge cases. -- Mono is being left "as is" for now since their inliner isn't as robust as the RyuJIT one, but we should be able to independently investigate removing the Mono support for the xplat APIs as well so they only need to support the platform specific APIs.

CC. @dotnet/jit-contrib

Likely regressions:
Windows x64:dotnet/perf-autofiling-issues#36075,dotnet/perf-autofiling-issues#36067
Linux x64:dotnet/perf-autofiling-issues#36054,dotnet/perf-autofiling-issues#36055
Windows arm64:dotnet/perf-autofiling-issues#36252,dotnet/perf-autofiling-issues#36251,dotnet/perf-autofiling-issues#36216,dotnet/perf-autofiling-issues#36215,dotnet/perf-autofiling-issues#36623
Linux arm64:dotnet/perf-autofiling-issues#36174

cc:@tannergooding

wasm regressions heredotnet/perf-autofiling-issues#36108 (aot) and improvementsdotnet/perf-autofiling-issues#36093 (interp)

cc@radekdoulik

Likely regressions:

These should be resolved with#103177

wasm regressions heredotnet/perf-autofiling-issues#36108 (aot)

Little bit surprised thatwasm aot regressed since the Mono handling hadn't been touched and the AOT support should have already been accelerated for these APIs. Is the support for PackedSIMD separate from the mainline Mono support around MonoLLVM?

improvementsdotnet/perf-autofiling-issues#36093 (interp)

👍, fairly significant improvements at that. I know thatinterp hadn't accelerated the Vector2/3/4 APIs but had accelerated the Vector128 APIs, so lets it do less work and still get the benefits.

Likely regressions:

These should be resolved with#103177

wasm regressions heredotnet/perf-autofiling-issues#36108 (aot)

Little bit surprised thatwasm aot regressed since the Mono handling hadn't been touched and the AOT support should have already been accelerated for these APIs. Is the support for PackedSIMD separate from the mainline Mono support around MonoLLVM?

I find it surprising too,@radekdoulik can you take a look at our codegen here please

improvementsdotnet/perf-autofiling-issues#36093 (interp)

👍, fairly significant improvements at that. I know thatinterp hadn't accelerated the Vector2/3/4 APIs but had accelerated the Vector128 APIs, so lets it do less work and still get the benefits.

Yes, nice improvements

Possibly related noticeable size improvements on Mono iOS HelloWorlddotnet/perf-autofiling-issues#35768