Skip to content

Conversation

@davidwrighton
Copy link
Member

  • If there is one associated, we will get the method handle. This is an optional parameter, as is the logic to get the existing result.
  • This will be used in the interpreter to generate different bytecode that knows about calling managed methods when needed
  • There is also some prior interest from the JIT team about using such an api, but it didn't quite get in. See PR Add pMethod param to getHelperFtn EE-JIT API #110267. This PR takes the comment from @jkotas into account to adjust the signature of the method to be something which is simpler and easier to understand

- If there is one associated, we will get the method handle. This is an optional parameter, as is the logic to get the existing result.
- This will be used in the interpreter to generate different bytecode that knows about calling managed methods when needed
- There is also some prior interest from the JIT team about using such an api, but it didn't quite get in. See PR dotnet#110267. This PR takes the comment from @jkotas into account to adjust the signature of the method to be something which is simpler and easier to understand
@github-actions github-actions bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 12, 2025
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR updates the JIT interface helper functions to support retrieving the CORINFO_METHOD_HANDLE and native entry point via a new API signature. Key changes include:

  • Changing the getHelperFtn signature in several headers and implementations from returning a void* to using output parameters (CORINFO_CONST_LOOKUP and CORINFO_METHOD_HANDLE).
  • Propagating the new API usage across various JIT components and code generators.
  • Adjusting call sites to handle the new lookup structure and access type semantics.

Reviewed Changes

Copilot reviewed 31 out of 31 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
src/coreclr/tools/aot/jitinterface/jitinterface_generated.h Updated getHelperFtn signature to include native entrypoint and method handle.
src/coreclr/tools/Common/JitInterface/ThunkGenerator/ThunkInput.txt Modified helper function parameter types to use REF_CORINFO_CONST_LOOKUP.
src/coreclr/jit/CorInfoImpl_generated.cs Adjusted managed wrapper for getHelperFtn to match new signature.
src/coreclr/jit/CorInfoImpl.cs Updated managed implementation of getHelperFtn using the new API.
src/coreclr/jit/lower.cpp, importer.cpp, compiler.* Updated call sites for helper functions to use CORINFO_CONST_LOOKUP instead of raw pointers.
src/coreclr/jit/codegen*.* Updated helper lookup usage across various code generators.
src/coreclr/inc/* Updated declarations for getHelperFtn in the EE interface definition.

{
params.addr = nullptr;
assert(helperFunction.accessType == IAT_PVALUE);
void* pAddr = helperFunction.addr;
Copy link

Copilot AI Jun 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The variable 'pAddr' is declared in the else block but never used. Removing this redundant declaration would improve code clarity.

Copilot uses AI. Check for mistakes.
{
params.addr = nullptr;
assert(helperFunction.accessType == IAT_PVALUE);
void* pAddr = helperFunction.addr;
Copy link

Copilot AI Jun 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The redundant declaration of 'pAddr' in the else branch is not used; consider removing it to simplify the code.

Suggested change
void* pAddr = helperFunction.addr;

Copilot uses AI. Check for mistakes.
// If we don't have a matched VM, we won't get valid results when asking for a helper function.
addr = (void*)(uintptr_t)(0xCA11CA11); // "callcall"
lookup.addr = (void*)(uintptr_t)(0xCA11CA11); // "callcall"
lookup.accessType = IAT_VALUE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we add a new IAT_ enum for 'nothing' so that anything that switch()es on the accessType will fail fast?


[UnmanagedCallersOnly]
private static void* _getHelperFtn(IntPtr thisHandle, IntPtr* ppException, CorInfoHelpFunc ftnNum, void** ppIndirection)
private static void _getHelperFtn(IntPtr thisHandle, IntPtr* ppException, CorInfoHelpFunc ftnNum, CORINFO_CONST_LOOKUP* pNativeEntrypoint, CORINFO_METHOD_STRUCT_** pMethod)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this makes me wonder whether it should be called ppMethod instead

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, not really... a method is a CORINFO_METHOD_STRUCT_* ... the first pointer is just part of being a method. This is just messy interop things, since we couldn't use a normal struct here to represent a typedef, since pointers and structs that only have a pointer in them are represented differently in the native ABI on some platforms. @max-charlamb recently talked to @jkoritzinsky and we now have an actual clean way to represent this using the p/invoke source generator (this is the CustomMarshalerAttribute support), but this logic predates that feature by several years.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah at some point we should be able to move to source-gen interop for this. Would require us to productize our "vtables but not COM" generator though (or make the JIT-EE interface build off of IUnknown just enough for the COM generator to interface well).

Packet_NotifyInstructionSetUsage = 229,
Packet_GetAsyncInfo = 230,
Packet_GetAsyncResumptionStub = 231,
Packet_GetHelperFtn = 233,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is needed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that if you change the size of contents of the data packet in SPMI you need a new magic number. See MethodContext::MethodInitHelper. Since this PR changes the definition of what the LWM map for GetHelperFtn is, I updated the magic value.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not needed -- the JIT-EE GUID update is sufficient.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would also be nice to fix the wrong type added in #116449 (comment) (since you're going to have to resolve merge conflicts anyway...)

@kg
Copy link
Member

kg commented Jun 12, 2025

LGTM overall

@EgorBo
Copy link
Member

EgorBo commented Jun 12, 2025

Bumping JIT-EE guid is hot these days 🙂

@dotnet-policy-service
Copy link
Contributor

Tagging @dotnet/jit-contrib for JIT-EE GUID update

@davidwrighton davidwrighton enabled auto-merge (squash) June 12, 2025 23:09
else
// We never return a method handle from the managed implementation of this method today
if (pMethod != null)
*pMethod = null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will want to fix this if/once JIT starts doing helper inlining. cc @EgorBo

@risc-vv
Copy link

risc-vv commented Jun 13, 2025

a6513e3 is being scheduled for building and testing

GIT: a6513e36266ea31f26c432b37f515f944f151418
REPO: dotnet/runtime
BRANCH: main

@sirntar
Copy link
Member

sirntar commented Jun 13, 2025

@dotnet/samsung

@davidwrighton
Copy link
Member Author

/ba-g these failures are known and unrelated

@davidwrighton davidwrighton merged commit 4623289 into dotnet:main Jun 13, 2025
96 of 99 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Jul 14, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants