[Wasm RyuJit] ABI classifier and Wasm stack arg preliminaries #123262
Conversation
* Add ABI classification for struct args. * Add the Wasm SP as the first arg * Add the PE pointer as last arg Not adding SP or PE as an arg to calls yet. Adjust things in the JIT that assumed LclNum 0 for instance methods was "this".
|
@dotnet/jit-contrib FYI Still trying to scope how much to do here; I may add more on top, eg plumbing this through to call sites. It might have been easier / more consistent with other non-IL args to place the Wasm SP as "first after |
|
Seems like I broke x86; taking a look. |
Will codegen be easier if we put SP at the end? Then the call opcode can be responsible for pushing SP before generating a call, instead of us having to generate a treenode for it and put it at the front of the evaluation order. |
Maybe a little easier, but not a lot. We might be able to defer creating the IR for the arg until morph or lower so there's be less IR. SP is left implicit in most other targets until fairly late. But I think there's just some assumption about arg 0 I missed. The other benefit of "at end" is that the helper wrappers don't have to do arg shuffles, but I'm not sure that is super important either. |
|
Placing the SP at the end would compromise its advantage as the likely-to-be-enregistered-by-the-native-engine hot argument.
I think we'll need to insert it in morph like other "special" arguments, since the ABI clafficiation depends on all ABI-relevant arguments being present.
If it turns out to be a problem (which seems unlikely), we can always a "dummy" parameter to the native implementation methods so that things line up. |
|
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
I've decided to do a bespoke function for WASM, mainly due to the awkwardness of porting the register mask code that would be of questionable value. Instead, we place an allocation constraint on the RA. With these changes, we are very close to getting a functional "add(x, y)". The only remaining part is the SP arg, being worked on in #123262. This is not a fully sound implementation since we have a limit on the number of instructions in the prolog (and here we're generating a potentially unbounded number of instruction). I've put a point about this into #121865. It seems this single-IG restriction ought to be fixable...
Not adding SP or PE as an arg to calls yet.
Adjust things in the JIT that assumed LclNum 0 for instance methods was "this".