[Wasm RyuJIT] Basic WASM codegen

[kg]

Basic Wasm Codegen

Before we can move on to more complex stages of the Wasm backend we need to do initial setup work for the core codegen. This means cloning the architecture specific files like lower and lsra for wasm, and going through and applying ifdefs in the correct places to disable/enable architecture-specific logic in the common files.

Lowering, LSRA, and emitting for Wasm will be different from most architectures since there are not formally 'registers' to lower to and there are not myriad encodings of specific opcodes, nor equivalents to things like lea. So ideally these new files will be much smaller than the equivalents for arm64 or x64, and closer in size to riscv (at least at first).

The Wasm equivalent of LSRA will be assigning values to native Wasm locals instead of registers, with the caveat that managed references will need to live in linear memory to be visible to GC (because the GC cannot scan native locals).

(incomplete, work in progress)

[dotnet-policy-service]

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

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• [User Story] RyuJIT for WebAssembly (Wasm) #121141

[SingleAccretion]

I am now working on bringing the initial Wasm-targeting Jit up. So far my thinking is along these lines:

1. We will introduce another 'layer' of backend code, which will be shared among WASM and non-WASM backend. This relates to lower, codegen, and emit. Above it will sit the current layer of "shared code for targets with a fixed register set". Names for these concepts are TBD.
   • This will involve moving some code around. It will not be part of the initial change, where I plan to simply exclude current codegen code.
   • Q: is there value in sharing code at codegen level?
   • A: yes, since we will want at least debug value range tracking to work.
2. We will need to augment the concept of registers (regNumber), since WASM has an infinite number of them. There are 3 options:
   • Say that WASM has no registers and tweak the frontend APIs that use them (esp. around ABI) to use some different abstraction.
   • Say that WASM's regNumber represents a register "class"/"type" (i32/i64/...).
   • Say that WASM's regNumber represents a true-to-life local index (and perhaps a special value for the value stack).
     • I suspect this is what we will end up with, since it is the most natural representation for codegen purposes. However, it does either requires 'packing' information into regNumber about the class/type, or maintaining a table on the side.