[Wasm RyuJit] Fix: Move implReadyToRunUnsupported() call for funclets before wasm codegen

[adamperlin]

This fixes a bug where we:

1. Compile a method under opts that inlines a method with EH, including full generation of code + host relocations
2. Bail out immediately after because of funclets
3. Recompile the method within the JIT (using the goto START handling in compiler.cpp) without minopts
4. Successfully recompile, because we don't inline the method that needs funclets this time
5. Leave stale relocations on the host side from the original optimized compilation with the inlinee.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR fixes a Wasm ReadyToRun compilation bug where a first (optimized) compilation attempt could record relocations and then bail out due to funclets, followed by a successful minopts recompile that left stale host-side relocations from the first attempt.

Changes:

• Move the Wasm funclet-based implReadyToRunUnsupported() bailout to occur before any codegen/emission work begins.
• Expand the comment to document the optimized-then-minopts recompilation edge case and why the bailout must be early.

[kg]

This seems like an adequate fix and will address something else I ran into most likely. I'm guessing cleaning up the stale relocs from the retry is too hard? I'm thinking 'stale relocs from retries' is something we need to be able to handle more generally since under normal circumstances (AFAIK) retries can happen and should work.

[adamperlin]

This seems like an adequate fix and will address something else I ran into most likely. I'm guessing cleaning up the stale relocs from the retry is too hard?

Yeah, I'm not sure there's an easy way to signal back to the host that it needs to clear out any relocs it recorded for the current method before we retry. One thing we could maybe do is add a new JIT/EE interface that signals this? That might be the best thing to do long term.

[kg]

This seems like an adequate fix and will address something else I ran into most likely. I'm guessing cleaning up the stale relocs from the retry is too hard?

Yeah, I'm not sure there's an easy way to signal back to the host that it needs to clear out any relocs it recorded for the current method before we retry. One thing we could maybe do is add a new JIT/EE interface that signals this? That might be the best thing to do long term.

This would address the issues I hit where a late retry causes us to try and overwrite write-once boundaries and vars in the host, see https://github.com/dotnet/runtime/pull/126932/changes#diff-01e22eff46505ee20d75dd64c72a9eb57d67f28f22a76258300bbe44dca59a14R1582

@jkotas @AndyAyersMS do you think we should add a new host 'retrying' signal that clears out state like this? I'm leaning towards yes but it is something that will rarely get called so I expect we will accumulate technical debt around it (i.e. 'oh, we added this new piece of state but forgot to add it to the ResetForJitRetry EE API')

[jkotas]

ResetForJitRetry

The robust way to implement this would be to return from the JIT with an error code and allow the host side to create a fresh compilation context for the retry so that we do not need to worry about cleaning up every bit of state.

(I know there is an existing ResetForJitRetry internal VM method for the runtime JIT. I do not think it is a good idea to promote this method to be on JIT/EE interface.)

[adamperlin]

@AndyAyersMS also had the idea that we could disable the "retry compilation with minopts" logic for R2R entirely, though I'm not sure what the full implications of that would be.

[jkotas]

"retry compilation with minopts" logic for R2R entirely,

It may be ok for R2R where we have a fallback to JIT or interpreter at runtime. I would not be ok for JIT or NAOT - there is no fallback for those.

The AOT compilers already make a distinction between these two cases when the fallback compilation is not enough:

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Lines 388 to 392 in 7cd318d

	#if READYTORUN
	throw new RequiresRuntimeJitException("JIT implementation limitation");
	#else
	ThrowHelper.ThrowInvalidProgramException();
	#endif