[Wasm RyuJit] Call Codegen Fixes for R2R by adamperlin · Pull Request #126778 · dotnet/runtime

adamperlin · 2026-04-10T23:33:31Z

This is another cherry-picked commit from #126662; There are a few cases in Wasm codegen where we needed an extra layer of indirection to load a PEP or call target, since the host provides symbols which resolve to indirection cells for calls, and we have indirection cell -> PEP -> target method.

…into locations in the R2R file work - Notably, a new level of indirection is needed

… in helper call codegen in Wasm

…-fix-call-codegen

dotnet-policy-service · 2026-04-10T23:34:42Z

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

Copilot

Pull request overview

This PR adjusts WebAssembly RyuJIT call lowering/emission for ReadyToRun (R2R) so call targets and PortableEntryPoints (PEPs) are loaded through the correct number of indirections when the host exposes symbols as indirection cells (indirection cell -> PEP -> target).

Changes:

Add an extra indirection when materializing the R2R indirection-cell argument on WASM so the value passed reflects the PEP rather than the cell itself.
Update WASM direct-call lowering for IAT_PVALUE to dereference through indirection cell -> PEP -> target.
Update WASM helper-call emission to load the PEP from the indirection cell (for managed helpers) and to load the final call target via an additional dereference.

Reviewed changes

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

File	Description
`src/coreclr/jit/morph.cpp`	Adds a WASM-specific extra indirection when preparing the R2R indirection-cell argument so the runtime sees the expected PEP pointer.
`src/coreclr/jit/lower.cpp`	Ensures WASM `IAT_PVALUE` direct call targets are lowered with an additional dereference to reach the actual dispatch target.
`src/coreclr/jit/codegenwasm.cpp`	Fixes helper-call emission to load the PEP from the indirection cell and to load the indirect call target by dereferencing the PEP.

adamperlin · 2026-04-10T23:57:34Z

src/coreclr/jit/codegenwasm.cpp

-        // Push the call target onto the wasm evaluation stack by dereferencing the PEP.
+        // Push the call target onto the wasm evaluation stack by dereferencing the indirection cell
+        // and then the PEP pointed to by the indirection cell.
        assert(helperFunction.accessType == IAT_PVALUE);


See if it's possible to use the new ADDR_REL reloc type for this to avoid the i32.const <address>; i32.load pattern.

AndyAyersMS · 2026-04-11T00:11:37Z

Maybe a picture would be useful here?

I imagine it something like this: We have an indirection cell that refers to a PEP which refers to a function index, which we then call indirectly.

jkotas · 2026-04-11T00:59:51Z

src/coreclr/jit/lower.cpp

                cellAddr->AsIntCon()->gtTargetHandle = (size_t)call->gtCallMethHnd;
 #endif
                GenTree* indir = Ind(cellAddr);
+#ifdef TARGET_WASM


The extra indirections related to portable entrypoints may want to be under if (opts.jitFlags->IsSet(JitFlags::JIT_FLAG_PORTABLE_ENTRY_POINTS))

jkotas · 2026-04-11T01:01:52Z

src/coreclr/jit/lower.cpp

 #endif
                GenTree* indir = Ind(cellAddr);
+#ifdef TARGET_WASM
+                indir = Ind(indir);    // WebAssembly "function pointers" are actually PortableEntryPoint pointers, and


The portable entrypoint needs to be also passed as the last argument. Where does that happen when we take this path?

jakobbotsch · 2026-04-11T09:43:39Z

src/coreclr/jit/lower.cpp

 #endif
                GenTree* indir = Ind(cellAddr);
+#ifdef TARGET_WASM
+                indir = Ind(indir);    // WebAssembly "function pointers" are actually PortableEntryPoint pointers, and


IAT_PPVALUE exists. Is there a reason it is not used by crossgen when it seems to be exactly what it wants here? It feels odd to return IAT_PVALUE and then have the JIT dereference it twice.

By the way, I would expect the optimization that is disabled for wasm above to result in large size savings if it was enabled.

It feels odd to return IAT_PVALUE and then have the JIT dereference it twice.

I think IAT_PVALUE is correct here, and it is going to make more sense once it follows the portable entry point ABI (see my other comment).

The portable entry point argument is being added in morph, near the morph change in this PR. I am not totally sure what it changes related to the number of indirections needed from the value returned by getFunctionEntryPoint though.
Do you mean that only one indirection is needed on top of the portable entry point argument? It is the optimization that is disabled above -- avoiding the duplication of the indirection cell.

IAT_PVALUE?

It is notable that with the current Jit-EE contract for portable entrypoints (where they're considered "direct" function pointers), the IAT_* values are now context-dependent. E. g. the function for SGCT PIs also returns "direct" IAT_VALUE values, but they won't need to be indirected.

FWIW, I think that in the ideal world, we would only have one place where the portable entrypoint flag would matter - with indirect managed calli, and the rest of the Jit would continue to operate on "native function pointer" semantics. But it's not where where we are going here it seems.

getAddressOfPInvokeTarget function.

PInvoke targets are unmanaged entrypoints. Unmanaged entrypoints are always direct. Managed entrypoints are always PEP. PEP vs. non-PEP Is implied by managed vs. unmanaged calling convention.

PEP ABI

The actual function pointer and the hidden argument must always come from the same pep value. For example, the following code is not valid with PEP ABI:

void* pep1 = <globally visible memory location>; void* pep2 = <globally visible memory location>; (*(void**)pep1)(arg0, arg1, ..., argN, pep2)

It will be eventually crucial for multithreading. Before multithreading, it can lead to subtle bugs if there is code with side-effects inserted between the two reads of globally visible memory location and the side-effects happen to update the globally visible memory location. (R2R indirection cells are globally visible memory locations for the purpose of this example.)

The optimization we do for other targets (which certainly cannot be incorrect since the the indirection cell is a constant in those cases) can certainly be done in IR to make it robust and make it work in WASM. In fact this old change was doing exactly that: #65388

PInvoke targets are unmanaged entrypoints. Unmanaged entrypoints are always direct. Managed entrypoints are always PEP. PEP vs. non-PEP Is implied by managed vs. unmanaged calling convention.

It is odd in the JIT to have IAT_VALUE mean "perform a call by calling with this index" in one case and IAT_VALUE mean "perform a call by indirecting then calling with this index" in another. I do not see what the calling convention has to do with anything here, we are generating an instruction in the end that takes an operand and it has no thoughts about calling conventions.

Something else to consider (in favor of non-contextual IAT_VALUE reading) is that we may legitimately want to call managed methods directly (WASM call) even with portable entrypoints, e. g. for known helpers that we'll import or functions in the same module (assuming we'll be able to make that optimization at some point).

I do not see what the calling convention has to do with anything here

https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/clr-abi.md#portable-entrypoints talks about it as managed calling convention (look for "the managed calling convention is modified as follows:")

If it is too confusing, we can use different terminology and assign different meaning to IAT_... enum with portable entry points at the JIT/EE interface level as long as the actual code remains the same. If we do changes along these lines, we should change the runtime JIT/EE interface used by the interpreter to match.

Something else to consider (in favor of non-contextual IAT_VALUE reading) is that we may legitimately want to call managed methods direct

Yes, we have discussed that as a potential future optimization. In theory, it can be used for managed method -> managed method calls too.

SingleAccretion · 2026-04-11T14:47:31Z

src/coreclr/jit/morph.cpp

-
+#if defined(TARGET_WASM)
+        // On WASM, the address in the R2R table is actually the address of something that should
+        // be treated as a PortableEntryPoint. To actually dispatch, we need to indirect once more.


What is the reason we can't avoid this indirection? Requirement to allocate "runtime-shaped" PEPs dynamically (can the R2R cell be a superclass of a PEP layout-wise, or vice-versa)?

davidwrighton and others added 3 commits April 9, 2026 13:44

Add codegen changes to make calls through PortableEntryPoints stored …

0b80545

…into locations in the R2R file work - Notably, a new level of indirection is needed

Add additional comment about the need for second level of indirection…

9c88d47

… in helper call codegen in Wasm

Merge branch 'main' of github.com:dotnet/runtime into adamperlin/wasm…

7141714

…-fix-call-codegen

Copilot AI review requested due to automatic review settings April 10, 2026 23:33

github-actions bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 10, 2026

dotnet-policy-service bot assigned adamperlin Apr 10, 2026

Copilot started reviewing on behalf of adamperlin April 10, 2026 23:34 View session

adamperlin changed the title ~~[Wasm RyuJit] Call Codegen Fixes~~ [Wasm RyuJit] Call Codegen Fixes for R2R Apr 10, 2026

adamperlin requested review from AndyAyersMS and kg April 10, 2026 23:34

Copilot AI reviewed Apr 10, 2026

View reviewed changes

adamperlin commented Apr 10, 2026

View reviewed changes

jkotas reviewed Apr 11, 2026

View reviewed changes

build-analysis bot mentioned this pull request Apr 11, 2026

System.Net.NameResolution.Tests DNS failures: Name or service not known #126641

Open

jakobbotsch reviewed Apr 11, 2026

View reviewed changes

SingleAccretion reviewed Apr 11, 2026

View reviewed changes

Conversation

adamperlin commented Apr 10, 2026

Uh oh!

dotnet-policy-service bot commented Apr 10, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AndyAyersMS commented Apr 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas Apr 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas Apr 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

jkotas Apr 11, 2026 •

edited

Loading

jkotas Apr 12, 2026 •

edited

Loading