[Wasm RyuJit] Use CORINFO_HELP_INITCLASS for fgGetSharedCCtor#126130
[Wasm RyuJit] Use CORINFO_HELP_INITCLASS for fgGetSharedCCtor#126130AndyAyersMS wants to merge 1 commit intodotnet:mainfrom
Conversation
github-actions
bot
added
the
area-CodeGen-coreclr
|
@davidwrighton PTAL This fixes a crash in the jit for debug SPC, compiling Old behavior would ask for a compact R2R helper, then try and insert a null tree. |
There was a problem hiding this comment.
Pull request overview
Updates Wasm JIT behavior so shared class constructor initialization uses CORINFO_HELP_INITCLASS, avoiding other shared statics/ReadyToRun helper paths for Wasm.
Changes:
- Add a Wasm-specific early return in
Compiler::fgGetSharedCCtorthat emitsCORINFO_HELP_INITCLASSviafgGetStaticsCCtorHelper.
|
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
| GenTreeCall* Compiler::fgGetSharedCCtor(CORINFO_CLASS_HANDLE cls) | ||
| { | ||
| #if defined(TARGET_WASM) | ||
| return fgGetStaticsCCtorHelper(cls, CORINFO_HELP_INITCLASS); |
There was a problem hiding this comment.
It would deserve a comment on why WASM is different. Is it because we don't have the synthetic helper implemented, or we don't think it is a good idea to use it, or...?
There was a problem hiding this comment.
@davidwrighton what would be the best explanation? I vaguely recall the compact R2R helpers use some encoding trick that maybe we can't use for Wasm?
There was a problem hiding this comment.
The dynamically created helpers rely on the ability of the runtime to generate new code at runtime. It turns out we could possibly work around that in many cases, but this is the simple path. We may change back to having synthetic helper creation in the future for WASM. OTOH, @jkotas and I have been talking about reducing usage of the synthetic helpers even on our existing platforms. It's not entirely clear that they are a win.
No description provided.