[Wasm RyuJIT] Initial scaffolding for calls and helper calls #123044

kg · 2026-01-09T20:37:12Z

Depends on #123021

Starting to put together all the code we need for helper calls and calls in general.

dotnet-policy-service · 2026-01-09T20:38:10Z

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

AndyAyersMS

We still need to figure out in detail how to specify what method we want to call.

We know roughly what kind of Wasm we want to produce (per the calling convention doc we'll be making lots of indirect calls) but we need help from the JIT host to make this all work out.

I think it might be ok for now to just defer this part of the work and try and get everything else lined up?

src/coreclr/jit/codegenwasm.cpp

AndyAyersMS · 2026-01-16T01:01:49Z

src/coreclr/jit/codegenwasm.cpp

+            // Generate a direct call to a non-virtual user defined or helper method
+            assert(call->IsHelperCall() || (call->gtCallType == CT_USER_FUNC));
+
+            if (call->gtEntryPoint.addr != NULL)


Per the calling convention, for user and helper calls we'll also be invoking them indirectly.

Right. I'm not clear on whether that means there won't be an addr filled in

kg · 2026-01-16T04:26:41Z

This branch now hits this in crossgen2:

Z:\runtime\src\coreclr\jit\codegenwasm.cpp:1123
Assertion failed 'NYI_WASM: load call target from indirection cell in register' in 'Program:callVoidFunc()' during 'Generate code' (IL size 8; hash 0x4bd04ee2; MinOpts)

kg · 2026-01-16T22:48:21Z

For this:

    [MethodImpl(MethodImplOptions.NoInlining)]
    static void voidFunc () {
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static void callVoidFunc () {
        voidFunc();
    }

R2R now compiles without crashing or asserting, and disasmo generates this:

; Method Program:callVoidFunc() (FullOpts)
G_M45341_IG01:  ;; offset=0x0000
            local.cnt 4
            local[0] type=i32
            local[1] type=i64
            local[2] type=f32
            local[3] type=f64
						;; size=9 bbWeight=1 PerfScore 5.00

G_M45341_IG02:  ;; offset=0x0009
            i32.const 140722950757336
            i32.load 0 0
            call_indirect 0 0
						;; size=14 bbWeight=1 PerfScore 3.00

G_M45341_IG03:  ;; offset=0x0017
            end
						;; size=1 bbWeight=1 PerfScore 1.00
; Total bytes of code: 24

It's not correct but it's a start.

kg · 2026-01-16T22:50:18Z

cc @dotnet/jit-contrib need to figure out how this should actually be factored and shaped and implemented, now that it "works". I don't understand 75% of the code I touched here, for example whether we use EA_8BYTE or a different one still makes no sense to me, and the way we historically separate out emitNewInstrXxx from emitIns_Xxx seems arbitrary. But this is my best guess at how everything should be arranged to make sense for wasm.

src/coreclr/jit/codegenwasm.cpp

AndyAyersMS · 2026-01-22T15:57:01Z

@kg what do we need to do to unblock this?

I don't think we'll have the crossgen2 relocation stuff around for a bit, so emitting long-form placeholder values for the various indices/offsets is the best we can do. If you want to try getting the reloc machinery started with this PR then we can look into that too.

kg · 2026-01-22T16:58:35Z

@kg what do we need to do to unblock this?

I don't think we'll have the crossgen2 relocation stuff around for a bit, so emitting long-form placeholder values for the various indices/offsets is the best we can do. If you want to try getting the reloc machinery started with this PR then we can look into that too.

As far as I'm concerned it's done, but I was waiting for someone to review it on the presumption that there's a bunch of things wrong in this PR since I didn't really know what I was doing.

AndyAyersMS · 2026-01-22T20:13:20Z

@kg what do we need to do to unblock this?
I don't think we'll have the crossgen2 relocation stuff around for a bit, so emitting long-form placeholder values for the various indices/offsets is the best we can do. If you want to try getting the reloc machinery started with this PR then we can look into that too.

As far as I'm concerned it's done, but I was waiting for someone to review it on the presumption that there's a bunch of things wrong in this PR since I didn't really know what I was doing.

We should be able to do some testing, especially now that #123262 is in. What happens if we try and compile a method that has a call (eg fact or something equally simple).

kg · 2026-01-22T20:19:39Z

@kg what do we need to do to unblock this?
I don't think we'll have the crossgen2 relocation stuff around for a bit, so emitting long-form placeholder values for the various indices/offsets is the best we can do. If you want to try getting the reloc machinery started with this PR then we can look into that too.

As far as I'm concerned it's done, but I was waiting for someone to review it on the presumption that there's a bunch of things wrong in this PR since I didn't really know what I was doing.

We should be able to do some testing, especially now that #123262 is in. What happens if we try and compile a method that has a call (eg fact or something equally simple).

Is this what you mean? #123044 (comment)

src/coreclr/jit/codegenwasm.cpp

SingleAccretion · 2026-01-22T20:08:40Z

src/coreclr/jit/emit.h

+    EC_MANAGED_PTR, // call_indirect to an unknown managed method or helper (two levels of indirection - ptr to
+                    // arbitrary cell)
+    // should generate: <push args>; call <func-index>
+    EC_FUNCTION_INDEX, // call to a known wasm import or function from same module, no indirection


For WASM we only have direct call and indirect call_indirect, which already map to EC_FUNC_TOKEN and EC_INDIR_R, so I don't think we need these kinds to be under ifdefs.

We don't have the concept of function pointers in wasm? Or is the idea that the extra level of indirection will be handled somewhere else?

The proposal is to use EC_FUNC_TOKEN for what is currently called EC_FUNCTION_INDEX, remove EC_MANAGED_CELL and EC_MANAGED_PTR by handling the indirections they represent in the caller(s), and using EC_INDIR_R to represent "emit call_indirect".

The overall principle is to have emitIns_Call only emit one WASM instruction, the call itself. It is (more) consistent with how other targets represent these things.

src/coreclr/jit/emit.h

src/coreclr/jit/emitfmtswasm.h

src/coreclr/jit/gentree.cpp

AndyAyersMS · 2026-01-22T21:59:18Z

We should be able to do some testing, especially now that #123262 is in. What happens if we try and compile a method that has a call (eg fact or something equally simple).

Is this what you mean? #123044 (comment)

Yes --make sure that basic cases look plausible

src/coreclr/jit/codegenwasm.cpp

AndyAyersMS · 2026-01-26T19:54:26Z

@kg somehow my comments never got posted, so some are out of date. At any rate I think we can just bypass calling LegalizeArgPlacement for Wasm, the stackifier should take care of this.

kg · 2026-01-26T20:08:38Z

FindEarliestPutArg also appears to call MarkCallPutArgAndFieldListNodes. I will try disabling legalization.

SingleAccretion · 2026-01-26T20:09:02Z

bypass calling LegalizeArgPlacement

That's true, but only because we don't have any stack arguments currently (were we to have them, we'd have PUTARG_STK, and FEATURE_FIXED_OUT_ARGS == 1. So if we disable it, some asserts will also need to be added. The alternative is to modify MarkPutArgAndFieldListNodes to skip marking non-putarg nodes under !HAS_FIXED_REGISTER_SET.

kg · 2026-01-26T22:47:53Z

FindEarliestPutArg also appears to call MarkCallPutArgAndFieldListNodes. I will try disabling legalization.

With legalization disabled:

Z:\runtime\src\coreclr\jit\lower.cpp:9274
Assertion failed 'arg->OperIsPutArg()' in 'Program:callVoidFunc()' during 'Lowering nodeinfo' (IL size 8; hash 0x4bd04ee2; MinOpts)

I think we can keep chasing all these down, but is it strictly necessary to get rid of putarg? What's bad about having it, at least for now?

kg · 2026-01-28T04:51:02Z

Generating: N002 (???,???) [000005] H----+-----                    t5 =    CNS_INT(h) int    0x420040 ftn
IN0004:             i32.const 4611686018431713344
                                                                        /--*  t4     int    arg1 $1
                                                                        +--*  t5     int    r2r cell $0
Generating: N003 (???,???) [000001] --CXG+-----                         *  CALL r2r_ind void   Program:voidFunc()

This is weird, according to the spew the constant is 0x420040 but we're seemingly getting a huge 64-bit constant (that I'm dutifully writing out for now). Or is that huge number the r2r cell address?
When writing constants do I need to mask off the high bits of what emitGetInsSC returns?

kg · 2026-01-28T04:59:51Z

In codegenwasm.cpp:

        case TYP_INT:
        {
            ins                      = INS_i32_const;
            GenTreeIntConCommon* con = treeNode->AsIntConCommon();
            bits                     = con->IntegralValue();
            assert(((INT64)(INT32)bits) == bits); // <- this fails
            break;
        }

It looks like we have TYP_INT constants with garbage in the high bits somehow.

kg · 2026-01-28T05:12:01Z

I think the problem is here:

    static var_types gtGetTypeForIconFlags(GenTreeFlags flags)
    {
        return flags == GTF_ICON_OBJ_HDL ? TYP_REF : TYP_I_IMPL;
    }

The value in gtNewIconHandleNode is a 64-bit handle (r2r cell address) but we're picking TYP_REF or TYP_I_IMPL for it which both get mapped to a 32-bit int on the wasm target. In this case it looks like we picked TYP_I_IMPL which becomes TYP_INT, and we have a 32-bit constant node with garbage in the high bits.

AndyAyersMS · 2026-01-28T17:16:25Z

The right long-term fix is to mark (the instr desc for) this constant as needing a reloc, and have the instr desc refer to the (64 bit) compile-time handle, and encode a maximum-length value in the constant field, and then have the emitter call emitRecordReloc with the instruction stream address of the cosntant field, the compile-time handle, and the fixup type (and also, fix the emit display to indicate what the constant refers to...).

The value we write into the constant can potentially be anything since it will be replaced by the reloc later on. Likely zero is a good choice, or perhaps the low 32 bits of the compile time handle.

For now you might just leave a todo for the reloc part and encode zero.

kg · 2026-01-28T17:37:26Z

Latest failure is outside crossgen in the test harness:

[CompileError: WebAssembly.compile(): Compiling function #7 failed: not enough arguments on the stack for call_indirect (need 4, got 1) @+674]

Two of those missing stack values are sp and pep but I'm not sure what the last one is, since I'm calling a void func.

kg · 2026-01-28T17:50:27Z

The missing PEP is easy to fix for now by generating an i32.const for it before a call.
The other missing arg is because the type index was wrong (we need a reloc to be fixed up by r2r). If I delete all the other managed methods from my test assembly, type index 0 becomes correct and I get this far:

Loading test-module.wasm...
Compiling test-module.wasm...
Instantiating test-module.wasm...
OK!
exports=["memory","table","wasm_test_Program__callVoidFunc","wasm_test_Program__voidFunc"]
running 'exports.wasm_test_Program__callVoidFunc(1024, 0)...
wasm://wasm/2afc428a:1


RuntimeError: table index is out of bounds
    at wasm://wasm/2afc428a:wasm-function[1]:0xb6
    at eval (eval at doEval (file:///E:/Documents/Projects/wasm-ryujit-runner/wasm-ryujit-runner.mjs:20:24), <anonymous>:1:9)
    at doEval (file:///E:/Documents/Projects/wasm-ryujit-runner/wasm-ryujit-runner.mjs:20:24)
    at file:///E:/Documents/Projects/wasm-ryujit-runner/wasm-ryujit-runner.mjs:18:5

This is because we currently have an empty function pointer table, so there's nothing callable in it to invoke (let alone at the index we have on the stack.)

adamperlin · 2026-01-28T18:07:27Z

This is because we currently have an empty function pointer table, so there's nothing callable in it to invoke (let alone at the index we have on the stack.)

Could you possibly post a disasm of what codegen looks like for this function now?

kg · 2026-01-28T18:12:56Z

This is because we currently have an empty function pointer table, so there's nothing callable in it to invoke (let alone at the index we have on the stack.)

Could you possibly post a disasm of what codegen looks like for this function now?

; Total bytes of code 41, prolog size 22, PerfScore 21.00, instruction count 21, allocated bytes for code 41 (MethodHash=4bd04ee2) for method Program:callVoidFunc() (MinOpts)
; ============================================================

*************** After end code gen, before unwindEmit()
G_M45341_IG01:        ; func=00, offs=0x000000, size=0x0016, bbWeight=1, PerfScore 11.00, gcrefRegs=00000000, byrefRegs=00000000, byref, nogc <-- Prolog IG

IN000a: 000000      local.cnt 0
IN000b: 000001      local.get 0
IN000c: 000003      i32.const 8
IN000d: 000005      i32.sub
IN000e: 000006      local.set 0
IN000f: 000008      local.get 0
IN0010: 00000A      local.get 0
IN0011: 00000C      i32.store 0 4
IN0012: 00000F      local.get 0
IN0013: 000011      local.get 1
IN0014: 000013      i32.store 0 0

G_M45341_IG02:        ; offs=0x000016, size=0x0012, bbWeight=1, PerfScore 9.00, gcrefRegs=00000000, byrefRegs=00000000, BB01 [0000], byref

IN0001: 000016      nop
IN0002: 000017      local.get 0
IN0003: 000019      i32.load 0 4
IN0004: 00001C      i32.const 0
IN0005: 00001E      i32.const 0
IN0006: 000020      i32.load 0 0
IN0007: 000023      call_indirect 0 0
IN0008: 000026      nop
IN0009: 000027      nop

G_M45341_IG03:        ; offs=0x000028, size=0x0001, bbWeight=1, PerfScore 1.00, epilog, nogc, extend

IN0015: 000028      end

adamperlin · 2026-01-28T18:49:18Z

IN0001: 000016 nop
IN0002: 000017 local.get 0
IN0003: 000019 i32.load 0 4
IN0004: 00001C i32.const 0
IN0005: 00001E i32.const 0
IN0006: 000020 i32.load 0 0
IN0007: 000023 call_indirect 0 0
IN0008: 000026 nop
IN0009: 000027 nop

I'm a bit confused about the load right before the call_indirect here. I thought the table entry index for call_indirect was encoded directly into the instruction, and didn't come from the stack? I would think we would need something like call_indirect (type index reloc) (table index reloc)

kg · 2026-01-28T18:53:13Z

IN0001: 000016 nop
IN0002: 000017 local.get 0
IN0003: 000019 i32.load 0 4
IN0004: 00001C i32.const 0
IN0005: 00001E i32.const 0
IN0006: 000020 i32.load 0 0
IN0007: 000023 call_indirect 0 0
IN0008: 000026 nop
IN0009: 000027 nop

I'm a bit confused about the load right before the call_indirect here. I thought the table entry index for call_indirect was encoded directly into the instruction, and didn't come from the stack? I would think we would need something like call_indirect (type index reloc) (table index reloc)

EDIT: It should always be either an indirection cell's address (for a direct call) or the address of an indirection cell's address (for an indirect call of a delegate or ftn ptr)

adamperlin · 2026-01-28T19:11:15Z

EDIT: It should always be either an indirection cell's address (for a direct call) or the address of an indirection cell's address (for an indirect call of a delegate or ftn ptr)

That makes sense, I managed to confuse myself reading the spec.

Checkpoint Fix build Wasm doesn't have special argument registers in the traditional sense, at least not yet Checkpoint Checkpoint Checkpoint Fix build R2R completes simple call without crashing Handle different callTypes Emit indirections Add comment jit-format Fix clang build Checkpoint cleanup Cleanup Cleanup Fix erroneous ifdef Clean up putarg dependencies

…a zero since the high bits might be garbage

…working on a real impl

Copilot

Pull request overview

This pull request adds initial scaffolding for call instructions and helper calls in the WebAssembly RyuJIT backend. The changes enable the compiler to generate direct calls, indirect calls, and tail calls for the WASM target.

Changes:

Add support for call-related WebAssembly instructions (call, call_indirect, return_call, return_call_indirect)
Implement emitIns_Call in the WASM emitter to handle different call types
Add code generation logic for calls in genCall, genCallInstruction, and genEmitHelperCall
Update lowering logic to handle WASM's lack of fixed register set
Exclude shared helper call allocation methods from WASM builds
Enhance constant generation to handle relocations

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
src/coreclr/jit/lower.cpp	Corrects preprocessor directive from `#ifdef` to `#if HAS_FIXED_REGISTER_SET`, adds guards for assertions that expect PutArg nodes which WASM doesn't use
src/coreclr/jit/instrswasm.h	Adds four new call instructions with proper opcodes and instruction formats
src/coreclr/jit/emitwasm.h	Removes unused method declarations for call instruction descriptors that are not needed for WASM
src/coreclr/jit/emitwasm.cpp	Implements `emitIns_Call` with support for direct and indirect calls, adds handling for IF_CALL_INDIRECT format in size calculation, output, and display methods
src/coreclr/jit/emitfmtswasm.h	Adds IF_CALL_INDIRECT instruction format definition
src/coreclr/jit/emit.cpp	Guards existing helper call allocation methods with `#ifndef TARGET_WASM` since WASM uses a different approach
src/coreclr/jit/codegenwasm.cpp	Implements call generation with `genCall`, `genCallInstruction`, and `genEmitHelperCall`; updates constant generation to handle relocations
src/coreclr/jit/codegencommon.cpp	Removes WASM-specific guard around `genEmitCallWithCurrentGC`, adds guard to exclude async resume functions from WASM

src/coreclr/jit/emitwasm.cpp

src/coreclr/jit/codegenwasm.cpp

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

kg · 2026-01-29T17:30:50Z

I'd like to try and finalize this so we can get it in. Crossgen successfully generates a valid module, though we can't actually perform the call since stuff like relocs is missing. I think the rest of the followup work should be done in separate PRs.

Copilot

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 7 comments.

src/coreclr/jit/codegenwasm.cpp

src/coreclr/jit/emitwasm.cpp

Copilot · 2026-01-29T17:35:06Z

src/coreclr/jit/lower.cpp

    } while (numMarkedNodes > 0);

+    // WASM-FIXME: !HAS_FIXED_REGISTER_SET ||
    assert(node->OperIsPutArg());


The WASM-FIXME comment suggests that the assertion at line 3106 may fail for WASM because !HAS_FIXED_REGISTER_SET means there are no PUTARG nodes. However, this function already returns nullptr at line 3088 if numMarkedNodes is 0, which would happen when MarkPutArgAndFieldListNodes returns 0 (as it does for WASM when there are no PutArg or FieldList nodes). The assertion may still be reachable if there are FieldList nodes without PutArg nodes. Consider whether this assertion should be conditional on HAS_FIXED_REGISTER_SET, or whether the early exit logic needs adjustment.

Suggested change

assert(node->OperIsPutArg());

assert(!HAS_FIXED_REGISTER_SET || node->OperIsPutArg());

Copilot · 2026-01-29T17:35:06Z

src/coreclr/jit/emitwasm.cpp

+        case IF_CALL_INDIRECT:
+        {
+            cnsval_ssize_t imm = emitGetInsSC(id);
+            printf(" 0 %llu", (uint64_t)imm);


The display format for IF_CALL_INDIRECT at line 720 shows "0 %llu" (table index, then type index), but the actual encoding at lines 539-541 outputs the type index first, then the table index. According to the WebAssembly specification, call_indirect should be encoded as: opcode, type_idx, table_idx. The encoding order is correct, but the display format should be updated to match: "printf(" %llu 0", (uint64_t)imm);" to show type index followed by table index.

Suggested change

printf(" 0 %llu", (uint64_t)imm);

printf(" %llu 0", (uint64_t)imm);

Copilot · 2026-01-29T17:35:07Z

src/coreclr/jit/emitwasm.cpp

+
+    instruction ins;
+
+    // FIXME-WASM: Currently while we're loading SP onto the stack we're not loading PEP, so generate one here.


This hardcoded PEP (Program Entry Point) value of 0 is a temporary workaround. The comment indicates this is because SP is loaded onto the stack but not PEP. This needs to be properly implemented before this code can work correctly. Consider tracking this with a more specific TODO or issue reference.

Suggested change

// FIXME-WASM: Currently while we're loading SP onto the stack we're not loading PEP, so generate one here.

// TODO-WASM: Push the actual Program Entry Point (PEP) instead of the placeholder 0 value here

// once PEP is properly propagated and loaded alongside SP in the WASM backend. See issue #NNNNN.

SingleAccretion · 2026-01-29T18:17:45Z

src/coreclr/jit/codegenwasm.cpp

 {
-    instruction    ins;
-    cnsval_ssize_t bits;
+    instruction    ins  = INS_unreachable;


Suggested change

instruction ins = INS_unreachable;

instruction ins = INS_none;

SingleAccretion · 2026-01-29T18:18:04Z

src/coreclr/jit/codegenwasm.cpp

+            // WASM-TODO: Generate reloc for this handle; 64-bit support
+            ins  = INS_i32_const;


Suggested change

// WASM-TODO: Generate reloc for this handle; 64-bit support

ins = INS_i32_const;

// WASM-TODO: Generate reloc for this handle

ins = INS_I_const;

SingleAccretion · 2026-01-29T18:18:11Z

src/coreclr/jit/codegenwasm.cpp

-        case TYP_DOUBLE:
+    }
+
+    if (ins == INS_unreachable)


Suggested change

if (ins == INS_unreachable)

if (ins == INS_none)

SingleAccretion · 2026-01-29T18:24:28Z

src/coreclr/jit/codegenwasm.cpp

+
+    assert(!call->IsTailCall());
+
+    genCallInstruction(call);


Arguments need to be consumed. Something like:

for (CallArg& arg : call->gtArgs.EarlyArgs()) { genConsumeReg(arg.GetEarlyNode()); } for (CallArg& arg : call->gtArgs.LateArgs()) { genConsumeReg(arg.GetLateNode()); }

SingleAccretion · 2026-01-29T18:26:53Z

src/coreclr/jit/codegenwasm.cpp

+    // Determine return value size(s).
+    const ReturnTypeDesc* pRetTypeDesc = call->GetReturnTypeDesc();


Suggested change

// Determine return value size(s).

const ReturnTypeDesc* pRetTypeDesc = call->GetReturnTypeDesc();

Unused.

SingleAccretion · 2026-01-29T18:56:28Z

src/coreclr/jit/emitwasm.cpp

+    // for the purpose of GC safepointing tail-calls are not real calls
+    id->idSetIsNoGC(params.isJump || params.noSafePoint || emitNoGChelper(params.methHnd));
+
+#ifdef DEBUG
+    if (EMIT_GC_VERBOSE)
+    {
+        if (id->idIsLargeCall())
+        {
+            printf("[%02u] Rec call GC vars = %s\n", id->idDebugOnlyInfo()->idNum,
+                   VarSetOps::ToString(emitComp, ((instrDescCGCA*)id)->idcGCvars));
+        }
+    }
+#endif
+


Suggested change

// for the purpose of GC safepointing tail-calls are not real calls

id->idSetIsNoGC(params.isJump || params.noSafePoint || emitNoGChelper(params.methHnd));

#ifdef DEBUG

if (EMIT_GC_VERBOSE)

{

if (id->idIsLargeCall())

{

printf("[%02u] Rec call GC vars = %s\n", id->idDebugOnlyInfo()->idNum,

VarSetOps::ToString(emitComp, ((instrDescCGCA*)id)->idcGCvars));

}

}

#endif

Same here; no GCInfo tracking in emit.

SingleAccretion · 2026-01-29T18:57:48Z

src/coreclr/jit/emitwasm.cpp

+            size += SizeOfULEB128(0);
+            size += SizeOfULEB128(emitGetInsSC(this));


Suggested change

size += SizeOfULEB128(0);

size += SizeOfULEB128(emitGetInsSC(this));

size += SizeOfULEB128(emitGetInsSC(this));

size += SizeOfULEB128(0);

Just to match the actual operand order.

SingleAccretion · 2026-01-29T19:00:46Z

src/coreclr/jit/lower.cpp

+                // WASM-FIXME
+                assert(!HAS_FIXED_REGISTER_SET || use.GetNode()->OperIsPutArg());


Suggested change

// WASM-FIXME

assert(!HAS_FIXED_REGISTER_SET || use.GetNode()->OperIsPutArg());

assert(!HAS_FIXED_REGISTER_SET || use.GetNode()->OperIsPutArg());

This is indeed how it should be.

SingleAccretion · 2026-01-29T19:04:16Z

src/coreclr/jit/lower.cpp

        }
    } while (numMarkedNodes > 0);

+    // WASM-FIXME: !HAS_FIXED_REGISTER_SET ||


Suggested change

// WASM-FIXME: !HAS_FIXED_REGISTER_SET ||

We're still only marking putargs (PUTARG_STK, which we don't use currently), so this assert is correct as-is.

SingleAccretion · 2026-01-29T19:12:56Z

src/coreclr/jit/emitwasm.cpp

+            // Indirect load of actual ftn ptr from indirection cell (on the stack)
+            emitIns_I(INS_i32_load, EA_PTRSIZE, 0);


I don't think we should push the concept of a function pointer being "the portable entrypoint" down into emitter. For example, we will have indirect unmanaged calls, which will use nakes table indices as function pointers. Obviously, for NAOT this won't hold as well. But it can be a TODO for now.

Suggested change

// Indirect load of actual ftn ptr from indirection cell (on the stack)

emitIns_I(INS_i32_load, EA_PTRSIZE, 0);

// Indirect load of actual ftn ptr from indirection cell (on the stack)

// TODO-WASM: temporary, move this into higher layers (lowering).

emitIns_I(INS_i32_load, EA_PTRSIZE, 0);

kg added arch-wasm WebAssembly architecture area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI labels Jan 9, 2026

dotnet-policy-service bot assigned kg Jan 9, 2026

kg force-pushed the wasm-genemithelpercall branch from 741ddb8 to e805a10 Compare January 15, 2026 00:03

AndyAyersMS mentioned this pull request Jan 15, 2026

[Wasm RyuJit] throw helper / null check preliminaries #123053

Merged

AndyAyersMS reviewed Jan 16, 2026

View reviewed changes

kg force-pushed the wasm-genemithelpercall branch from b95ce18 to 499127d Compare January 16, 2026 04:26

build-analysis bot mentioned this pull request Jan 16, 2026

System.Threading.Channels.Tests execution timed out #121873

Open

EgorBo reviewed Jan 17, 2026

View reviewed changes

src/coreclr/jit/codegenwasm.cpp Outdated Show resolved Hide resolved

This was referenced Jan 21, 2026

Unable to pull image from mcr.microsoft.com #117164

Open

"We stopped hearing from agent Azure Pipelines 32. Verify the agent machine is running and has a healthy network connection" dotnet/dnceng#1886

Open

SingleAccretion reviewed Jan 22, 2026

View reviewed changes

kg force-pushed the wasm-genemithelpercall branch from 774a027 to 3c2e14c Compare January 24, 2026 02:24

build-analysis bot mentioned this pull request Jan 24, 2026

[Test][UserEvents] Trace file does not contain expected events #123442

Open

AndyAyersMS reviewed Jan 26, 2026

View reviewed changes

This was referenced Jan 27, 2026

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

browser-wasm linux Release LibraryTests queues timing out #117974

Open

kg force-pushed the wasm-genemithelpercall branch from fc8c8bd to 83bc9d1 Compare January 28, 2026 17:37

kg added 5 commits January 29, 2026 09:04

Detect that an int or long constant needs a reloc and (for now) emit …

8e40508

…a zero since the high bits might be garbage

Remove incorrect comment

68e168d

Generate a placeholder PEP before call

9567c1f

Remove unnecessary partial implementation of nullcheck since andy is …

131a1b5

…working on a real impl

kg force-pushed the wasm-genemithelpercall branch from ab101b1 to 131a1b5 Compare January 29, 2026 17:16

Copilot AI review requested due to automatic review settings January 29, 2026 17:16

Copilot started reviewing on behalf of kg January 29, 2026 17:17 View session

Copilot AI reviewed Jan 29, 2026

View reviewed changes

kg and others added 2 commits January 29, 2026 09:23

Cleanup

adb7d50

Apply suggestions from code review

d91d875

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings January 29, 2026 17:29

Copilot started reviewing on behalf of kg January 29, 2026 17:29 View session

kg marked this pull request as ready for review January 29, 2026 17:30

Copilot AI reviewed Jan 29, 2026

View reviewed changes

jit-format

53f7b25

SingleAccretion reviewed Jan 29, 2026

View reviewed changes

	assert(node->OperIsPutArg());
	assert(!HAS_FIXED_REGISTER_SET \|\| node->OperIsPutArg());

	printf(" 0 %llu", (uint64_t)imm);
	printf(" %llu 0", (uint64_t)imm);


		instruction ins;

		// FIXME-WASM: Currently while we're loading SP onto the stack we're not loading PEP, so generate one here.

	// FIXME-WASM: Currently while we're loading SP onto the stack we're not loading PEP, so generate one here.
	// TODO-WASM: Push the actual Program Entry Point (PEP) instead of the placeholder 0 value here
	// once PEP is properly propagated and loaded alongside SP in the WASM backend. See issue #NNNNN.

	instruction ins = INS_unreachable;
	instruction ins = INS_none;

		// WASM-TODO: Generate reloc for this handle; 64-bit support
		ins = INS_i32_const;

		// Determine return value size(s).
		const ReturnTypeDesc* pRetTypeDesc = call->GetReturnTypeDesc();

		size += SizeOfULEB128(0);
		size += SizeOfULEB128(emitGetInsSC(this));

		// WASM-FIXME
		assert(!HAS_FIXED_REGISTER_SET \|\| use.GetNode()->OperIsPutArg());

		// Indirect load of actual ftn ptr from indirection cell (on the stack)
		emitIns_I(INS_i32_load, EA_PTRSIZE, 0);

[Wasm RyuJIT] Initial scaffolding for calls and helper calls #123044

Are you sure you want to change the base?

[Wasm RyuJIT] Initial scaffolding for calls and helper calls #123044

Conversation

kg commented Jan 9, 2026

Uh oh!

dotnet-policy-service bot commented Jan 9, 2026

Uh oh!

AndyAyersMS left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kg commented Jan 16, 2026

Uh oh!

kg commented Jan 16, 2026

Uh oh!

kg commented Jan 16, 2026

Uh oh!

Uh oh!

AndyAyersMS commented Jan 22, 2026

Uh oh!

kg commented Jan 22, 2026

Uh oh!

AndyAyersMS commented Jan 22, 2026

Uh oh!

kg commented Jan 22, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

SingleAccretion Jan 22, 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!

Uh oh!

Uh oh!

Uh oh!

AndyAyersMS commented Jan 22, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AndyAyersMS commented Jan 26, 2026

Uh oh!

kg commented Jan 26, 2026

Uh oh!

SingleAccretion commented Jan 26, 2026

Uh oh!

kg commented Jan 26, 2026

Uh oh!

kg commented Jan 28, 2026

Uh oh!

kg commented Jan 28, 2026

Uh oh!

kg commented Jan 28, 2026

Uh oh!

AndyAyersMS commented Jan 28, 2026

Uh oh!

kg commented Jan 28, 2026

Uh oh!

kg commented Jan 28, 2026

Uh oh!

adamperlin commented Jan 28, 2026

Uh oh!

kg commented Jan 28, 2026

Uh oh!

adamperlin commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SingleAccretion Jan 22, 2026 •

edited

Loading

adamperlin commented Jan 28, 2026 •

edited

Loading

kg commented Jan 28, 2026 •

edited

Loading