[Wasm RyuJIT] Initial scaffolding for calls and helper calls

[kg]

Depends on #123021

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

[dotnet-policy-service]

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?

[kg]

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]

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]

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.

[AndyAyersMS]

@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]

@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]

@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]

@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)

[AndyAyersMS]

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

[AndyAyersMS]

@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]

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

[SingleAccretion]

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]

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]

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.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (1)

src/coreclr/jit/lower.cpp:3106

• This FIXME comment suggests that for WASM (where HAS_FIXED_REGISTER_SET is 0), the assertion on the next line may not always hold. The comment indicates this needs to be addressed, but the assertion is not currently guarded. Consider either implementing the fix suggested in the FIXME or documenting why this assertion is safe to keep as-is for WASM.

    assert(node->OperIsPutArg());
    return node;

[AndyAyersMS]

I think we should merge this soon, the remaining issues can more easily sorted out once we get more of the supporting pieces in place.

[Copilot]

Pull request overview

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

[kg]

/ba-g Infra instability

[AndyAyersMS]

Great to see this get in! Thanks, @kg.