Generate calls to interface methods through resolve helper #112406

MichalStrehovsky · 2025-02-11T12:23:35Z

This changes interface calls when CFG is enabled to use a resolve helper instead of the stub dispatcher. I've also extended the CFG testing a bit to cover more of interface calls in the smoke test.

static int Call(IFoo f, int x, int y) => f.Call(x, y);

Before this change:

00007FF605971D50  push        rbx  
00007FF605971D51  sub         rsp,20h  
00007FF605971D55  mov         qword ptr [rsp+30h],rcx  
00007FF605971D5A  mov         r10d,edx  
00007FF605971D5D  mov         ebx,r8d  
00007FF605971D60  mov         rcx,qword ptr [__InterfaceDispatchCell_repro_Program_IFoo__Call_repro_Program__Call (07FF6059BEBD0h)]  
00007FF605971D67  call        qword ptr [__guard_check_icall_fptr (07FF6059CD558h)]  
00007FF605971D6D  mov         rax,rcx  
00007FF605971D70  mov         rcx,qword ptr [rsp+30h]  
00007FF605971D75  mov         r8d,ebx  
00007FF605971D78  mov         edx,r10d  
00007FF605971D7B  lea         r10,[__InterfaceDispatchCell_repro_Program_IFoo__Call_repro_Program__Call (07FF6059BEBD0h)]  
00007FF605971D82  call        rax  
00007FF605971D84  nop  
00007FF605971D85  add         rsp,20h  
00007FF605971D89  pop         rbx  
00007FF605971D8A  ret

After this change:

00007FF704181CF0  sub         rsp,28h  
00007FF704181CF4  lea         r10,[__InterfaceDispatchCell_repro_Program_IFoo__Call_repro_Program__Call (07FF7041CEBD0h)]  
00007FF704181CFB  call        RhpResolveInterfaceMethodFast (07FF703FFF5A0h)  
00007FF704181D00  call        qword ptr [__guard_dispatch_icall_fptr (07FF7041DD560h)]  
00007FF704181D06  nop  
00007FF704181D07  add         rsp,28h  
00007FF704181D0B  ret

dotnet-policy-service · 2025-02-11T12:24:16Z

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

MichalStrehovsky · 2025-02-12T22:43:25Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2025-02-12T22:43:42Z

Azure Pipelines successfully started running 1 pipeline(s).

This reverts commit 7f879d6.

MichalStrehovsky · 2025-02-13T17:29:21Z

For this not to be a throughput regression, we need to figure out a clean way to implement the hack in last two commits.

I ran JSON serialization with/without this PR. Having to preserve argument registers before calling the resolve helper costs us about 1% in throughput.

PR-hack is the hack where we allow RyuJIT to assume argument registers are not clobbered. We better not take a GC in the slow path.
PR is this PR without that hack.
Baseline is the vanilla CFG build.

Style	Attemp1 ms	Attemp2 ms	Attemp3 ms	Attemp4 ms	Attemp5 ms
PR-hack	1103	1105	1096	1102	1103
PR	1125	1126	1139	1127	1134
Baseline	1112	1105	1111	1104	1106

Do we have a way to do this hack cleanly that doesn't involve building a new universal transition?

MichalStrehovsky · 2025-02-17T12:50:19Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2025-02-17T12:50:31Z

Azure Pipelines successfully started running 1 pipeline(s).

MichalStrehovsky · 2025-02-17T22:51:43Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2025-02-17T22:51:52Z

Azure Pipelines successfully started running 1 pipeline(s).

Copilot reviewed 3 out of 22 changed files in this pull request and generated no comments.

Files not reviewed (19)

src/coreclr/inc/corinfo.h: Language not supported
src/coreclr/inc/jiteeversionguid.h: Language not supported
src/coreclr/inc/jithelpers.h: Language not supported
src/coreclr/jit/codegencommon.cpp: Language not supported
src/coreclr/jit/gentree.cpp: Language not supported
src/coreclr/jit/gentree.h: Language not supported
src/coreclr/jit/lower.cpp: Language not supported
src/coreclr/jit/morph.cpp: Language not supported
src/coreclr/jit/targetamd64.h: Language not supported
src/coreclr/jit/targetarm64.h: Language not supported
src/coreclr/nativeaot/Runtime/AsmOffsets.h: Language not supported
src/coreclr/nativeaot/Runtime/CMakeLists.txt: Language not supported
src/coreclr/nativeaot/Runtime/EHHelpers.cpp: Language not supported
src/coreclr/nativeaot/Runtime/StackFrameIterator.cpp: Language not supported
src/coreclr/nativeaot/Runtime/amd64/DispatchResolve.asm: Language not supported
src/coreclr/nativeaot/Runtime/amd64/UniversalTransition.asm: Language not supported
src/coreclr/nativeaot/Runtime/arm64/DispatchResolve.asm: Language not supported
src/coreclr/nativeaot/Runtime/arm64/UniversalTransition.asm: Language not supported
src/coreclr/nativeaot/Runtime/inc/rhbinder.h: Language not supported

Comments suppressed due to low confidence (1)

src/coreclr/tools/Common/JitInterface/CorInfoHelpFunc.cs:267

Ensure that the new helper CORINFO_HELP_INTERFACELOOKUP_FOR_SLOT is covered by tests to verify its behavior.

CORINFO_HELP_INTERFACELOOKUP_FOR_SLOT,  // Resolve a non-generic interface method from this pointer and dispatch cell

MichalStrehovsky · 2025-02-18T07:18:22Z

@dotnet/ilc-contrib this is ready for review

@jakobbotsch who would be the best to review the JIT side?

jakobbotsch · 2025-03-01T13:41:17Z

I pushed a commit to fix the JIT assert and also a probable fix for the GC stress issue (only based on review, haven't tested that one). Will kick off the CFG job again.

jakobbotsch · 2025-03-01T13:41:21Z

/azp run jit-cfg

azure-pipelines · 2025-03-01T13:41:31Z

Azure Pipelines successfully started running 1 pipeline(s).

jakobbotsch · 2025-03-01T23:55:29Z

There's still gcstress failures. I'm guessing there are some more fundamental issues around trying to give this helper a non standard calling convention where GC refs could be in the argument registers. I suspect they are not properly being reported and reflected back to the JIT on return.

jkotas · 2025-03-03T06:50:42Z

I suspect they are not properly being reported

The GC info produced by the JIT does not look right.

GC info without CFG - notice that tracking of rcx/rdx/r8/r9 is stopped after the interface call:

IN0003: 00000D mov      rcx, 0x1F972400BE8      ; data for Program:f
IN0004: 000017 mov      rcx, gword ptr [rcx]
                            ; gcrRegs +[rcx]
IN0005: 00001A mov      r9, 0x1F972400BF0      ; data for Program:o
IN0006: 000024 mov      r9, gword ptr [r9]
                            ; gcrRegs +[r9]
IN0007: 000027 mov      rdx, r9
                            ; gcrRegs +[rdx]
IN0008: 00002A mov      r8, r9
                            ; gcrRegs +[r8]
IN0009: 00002D mov      r11, 0x7FF91B770070      ; code for IFace:M(System.Object,System.Object,System.Object):this
IN000a: 000037 call     [r11]IFace:M(System.Object,System.Object,System.Object):this
                            ; gcrRegs -[rcx rdx r8-r9]
                            ; gcr arg pop 0

GC info with CFG - notice that tracking of rcx/rdx/r8/r9 is stopped before the interface call:

IN0003: 00000D mov      r11, 0x1F65D000BE8      ; data for Program:f
IN0004: 000017 mov      rcx, gword ptr [r11]
                            ; gcrRegs +[rcx]
IN0005: 00001A mov      r11, 0x1F65D000BF0      ; data for Program:o
IN0006: 000024 mov      r9, gword ptr [r11]
                            ; gcrRegs +[r9]
IN0007: 000027 mov      rdx, r9
                            ; gcrRegs +[rdx]
IN0008: 00002A mov      r8, r9
                            ; gcrRegs +[r8]
IN0009: 00002D mov      r11, 0x7FF8FB8B0070      ; code for IFace:M(System.Object,System.Object,System.Object):this
recordRelocation: 00007FF8FBBB3CE8 (rw: 000001F600575220) => 00007FF95B3DAB40, type 16 (IMAGE_REL_BASED_REL32), delta 0
IN000a: 000037 call     CORINFO_HELP_INTERFACELOOKUP_FOR_SLOT
                            ; gcrRegs -[rcx rdx r8-r9] <--- this looks wrong, it should be after call [CORINFO_HELP_DISPATCH_INDIRECT_CALL]
                            ; gcr arg pop 0
recordRelocation: 00007FF8FBBB3CEE (rw: 000001F600575226) => 00007FF95B98DCF0, type 16 (IMAGE_REL_BASED_DISP32), delta 0
IN000b: 00003C call     [CORINFO_HELP_DISPATCH_INDIRECT_CALL]
                            ; gcr arg pop 0

Test program source


class Program
{
    static IFace f = new C();
    static object o = new object();

    static void Main() 
    {
        f.M(o,o,o);
    }
}

interface IFace
{
   void M(object a, object b, object c);
}

class C : IFace
{
    public void M(object a, object b, object c) { }
}

jakobbotsch · 2025-03-03T08:23:39Z

I can look into that, but do you expect that this is going to make things work? My general wondering is if the runtime would know to report and relocate the GC refs in the argument registers of the transition frame if GC happens while inside the new helper.

jakobbotsch · 2025-03-03T10:02:18Z

/azp run jit-cfg

azure-pipelines · 2025-03-03T10:02:27Z

Azure Pipelines successfully started running 1 pipeline(s).

jakobbotsch · 2025-03-03T12:15:21Z

There's some more JIT work needed to properly report non callee saves after a call. I opened #113071 for it.
Still unsure if it will "just work" once the JIT reporting is right.

jkotas · 2025-03-03T16:55:04Z

My general wondering is if the runtime would know to report and relocate the GC refs in the argument registers of the transition frame if GC happens while inside the new helper.

The runtime knows how to do it for the existing VSD helper that tailcalls, so it should be able to do it for helper that returns as well. The new helper uses the same GC reporting setup as the existing VSD helper that tailcalls.

In order for this to work, the JIT has to setup all arguments before calling the new helper. It does not seem to be happening in all cases. For example, I see the following codegen for a call from Dictionary.FindValue to System.Collections.Generic.IEqualityComparer<string>.Equals(string,string):

...
00007ff8`f8b2d475 4c8bd8          mov     r11,rax
00007ff8`f8b2d478 498b1424        mov     rdx,qword ptr [r12]
00007ff8`f8b2d47c 488bcf          mov     rcx,rdi
00007ff8`f8b2d47f e8bcd6825f      call    coreclr!JIT_InterfaceLookupForSlot (00007ff9`5835ab40)
00007ff8`f8b2d484 488bcf          mov     rcx,rdi <--- unnecessary duplication, but it does not hurt
00007ff8`f8b2d487 4c8bc6          mov     r8,rsi <--- this needs to be before JIT_InterfaceLookupForSlot 
00007ff8`f8b2d48a ff156008de5f    call    qword ptr [00007ff9`5890dcf0] // JIT_DispatchIndirectCall
00007ff8`f8b2d490 85c0            test    eax,eax
...

jakobbotsch · 2025-03-03T17:08:54Z

In order for this to work, the JIT has to setup all arguments before calling the new helper. It does not seem to be happening in all cases. For example, I see the following codegen for a call from Dictionary.FindValue to System.Collections.Generic.IEqualityComparer<string>.Equals(string,string):

That's expected with how this is implemented in the JIT. The JIT just considers this helper to not trash the argument registers. It is free to leave any GC ref in those registers across the call. It is not considering the "resolve + dispatch" sequence as one unit that takes the arguments of the final call. (I am not sure if this would be feasible on arm64 that uses "resolve + validate + call" sequence).
What the JIT needs from the VM side here is that the VM side uses its reported GC information to update the argument registers of the transition frame (like it would already be doing for callee saves). Is it possible to make it do that?

jkotas · 2025-03-03T20:34:09Z

What the JIT needs from the VM side here is that the VM side uses its reported GC information to update the argument registers of the transition frame (like it would already be doing for callee saves). Is it possible to make it do that?

Yes, I have pushed a commit to do that (some of the changes in that commit are quick hack that needs cleaning up if it works).

Track all integer registers for calls in `regPtrDsc`. This does not cost any extra memory and it saves us from going back and forth between an intermediate format. It also unblocks proper GC reporting for helper calls that are GC reported with non-standard calling convention.

jakobbotsch · 2025-03-03T21:53:34Z

/azp run jit-cfg

azure-pipelines · 2025-03-03T21:53:42Z

Azure Pipelines successfully started running 1 pipeline(s).

Generate calls to interface methods through resolve helper

cb9785d

dotnet-issue-labeler bot added the area-NativeAOT-coreclr label Feb 11, 2025

dotnet-policy-service bot assigned MichalStrehovsky Feb 11, 2025

MichalStrehovsky mentioned this pull request Feb 11, 2025

Don't block inlining CORINFO_VIRTUALCALL_LDVIRTFTN #112400

Closed

jakobbotsch added 3 commits February 12, 2025 14:12

Expand resolver during CFG expansion

6bdcdb1

Revert register constraint changes

7f879d6

Nit

6d45447

MichalStrehovsky added 2 commits February 13, 2025 09:35

Revert "Revert register constraint changes"

9d0a3bd

This reverts commit 7f879d6.

Scary hack

2f0a285

MichalStrehovsky added 2 commits February 14, 2025 11:09

Universal transition

6cd6567

Arm64 and fixes

36fa432

Testing

312d75d

MichalStrehovsky added 2 commits February 18, 2025 08:14

Merge branch 'main' into resolvehelper

5249b9a

Update jiteeversionguid.h

b370b17

MichalStrehovsky force-pushed the resolvehelper branch from 342fb19 to b370b17 Compare February 18, 2025 07:15

MichalStrehovsky marked this pull request as ready for review February 18, 2025 07:17

Copilot bot review requested due to automatic review settings February 18, 2025 07:17

Copilot AI reviewed Feb 18, 2025

View reviewed changes

jakobbotsch added 3 commits March 1, 2025 14:38

Merge branch 'main' of github.com:dotnet/runtime into pr-112406

1ea2b34

Update JIT-EE GUID after merge

bb89b87

Run jit-format

5ca6411

jakobbotsch added 2 commits March 3, 2025 10:52

Fix Jan's bug, fix tailcall test

5d66c77

Fix build on targets without custom calling convention for helper

f28053d

jakobbotsch mentioned this pull request Mar 3, 2025

JIT: Simplify internal GC tracking structures #113071

Merged

jakobbotsch mentioned this pull request Mar 3, 2025

Remove unnecessary GcInfoEncoder::DoNotTrackInPartiallyInterruptible #113078

Merged

Delete unnecessary TAILJMP_RAX

d866b1e

Depend on the GCInfo produced by the JIT for reporting of arg registers

a70c650

jakobbotsch added 2 commits March 3, 2025 22:33

Remove check

42343da

dotnet deleted a comment Mar 3, 2025

jakobbotsch closed this Mar 3, 2025

jakobbotsch reopened this Mar 3, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Generate calls to interface methods through resolve helper #112406

Generate calls to interface methods through resolve helper #112406

MichalStrehovsky commented Feb 11, 2025 •

edited

Loading

dotnet-policy-service bot commented Feb 11, 2025

MichalStrehovsky commented Feb 12, 2025

azure-pipelines bot commented Feb 12, 2025

MichalStrehovsky commented Feb 13, 2025

MichalStrehovsky commented Feb 17, 2025

azure-pipelines bot commented Feb 17, 2025

MichalStrehovsky commented Feb 17, 2025

azure-pipelines bot commented Feb 17, 2025

MichalStrehovsky commented Feb 18, 2025

jakobbotsch commented Mar 1, 2025

jakobbotsch commented Mar 1, 2025

azure-pipelines bot commented Mar 1, 2025

jakobbotsch commented Mar 1, 2025

jkotas commented Mar 3, 2025

jakobbotsch commented Mar 3, 2025

jakobbotsch commented Mar 3, 2025

azure-pipelines bot commented Mar 3, 2025

jakobbotsch commented Mar 3, 2025

jkotas commented Mar 3, 2025

jakobbotsch commented Mar 3, 2025

jkotas commented Mar 3, 2025

jakobbotsch commented Mar 3, 2025

azure-pipelines bot commented Mar 3, 2025

Generate calls to interface methods through resolve helper #112406

Are you sure you want to change the base?

Generate calls to interface methods through resolve helper #112406

Conversation

MichalStrehovsky commented Feb 11, 2025 • edited Loading

dotnet-policy-service bot commented Feb 11, 2025

MichalStrehovsky commented Feb 12, 2025

azure-pipelines bot commented Feb 12, 2025

MichalStrehovsky commented Feb 13, 2025

MichalStrehovsky commented Feb 17, 2025

azure-pipelines bot commented Feb 17, 2025

MichalStrehovsky commented Feb 17, 2025

azure-pipelines bot commented Feb 17, 2025

Choose a reason for hiding this comment

MichalStrehovsky commented Feb 18, 2025

jakobbotsch commented Mar 1, 2025

jakobbotsch commented Mar 1, 2025

azure-pipelines bot commented Mar 1, 2025

jakobbotsch commented Mar 1, 2025

jkotas commented Mar 3, 2025

jakobbotsch commented Mar 3, 2025

jakobbotsch commented Mar 3, 2025

azure-pipelines bot commented Mar 3, 2025

jakobbotsch commented Mar 3, 2025

jkotas commented Mar 3, 2025

jakobbotsch commented Mar 3, 2025

jkotas commented Mar 3, 2025

jakobbotsch commented Mar 3, 2025

azure-pipelines bot commented Mar 3, 2025

MichalStrehovsky commented Feb 11, 2025 •

edited

Loading