Replace HELPER_METHOD_FRAME with DynamicHelperFrame in patchpoints

[davidwrighton]

• Consolidate the 2 functions so we only need 1 copy of the C++ code (JIT_Patchpoint and JIT_PartialCompilationPatchpoint are still separate entrypoints, but the real meat of the logic is now all in JIT_PatchpointWorkerWorkerWithPolicy)
• Instead of using a managed function, I decided to use a transition frame to manage the case of calling into the runtime. In this case we are able to re-use the DynamicHelperFrame which appears to be sufficient.
• Add asm helpers in the current architectures which support on stack replacement to setup the TransitionBlock and call into the common C++ code

[dotnet-policy-service]

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

[davidwrighton]

/azp run runtime-jit-experimental

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[am11]

Looks great, thank you!

A side/post-HMF question, do we have some alternative/deterministic mechanism to replace the two VirtualUnwind calls in JIT_PatchpointWorkerWorkerWithPolicy?

[am11]

Looks like we can remove the need of separateJIT_PartialCompilationPatchpoint if we update its only usage:

runtime/src/coreclr/jit/patchpoint.cpp

Lines 241 to 242 in d8a6117

	GenTreeCall* helperCall =
	compiler->gtNewHelperCallNode(CORINFO_HELP_PARTIAL_COMPILATION_PATCHPOINT, TYP_VOID, ilOffsetNode);

to be:

GenTree* nullCounter = compiler->gtNewIconNode(0, TYP_I_IMPL);
GenTreeCall* helperCall =
    compiler->gtNewHelperCallNode(CORINFO_HELP_PATCHPOINT, TYP_VOID, nullCounter, ilOffsetNode);

[AndyAyersMS]

I likely would have done this differently. The head and tail portions are similar, the middle part has the policy, so the middle part could have been handled via two different auxiliary methods.

If we ever productize partial compilation there will likely be further changes in that policy, so keeping it separated would be nice.

[AndyAyersMS]

jit-experimental has a known OSR failure #111625 which you are hitting, but the partial compilation failures are new to this PR.

[davidwrighton]

Following @jkotas and @AndyAyersMS comments I've refactored the policy logic significantly. It looks much better to me now, and I hope it looks good to them too. I'll re-run the jit experimental leg if this looks good in regular PR tests.

[AndyAyersMS]

Thanks -- this looks good.

[jkotas]

Could you please take at comments that are still open?

#112025 (review)
#112025 (review)

#112025 (comment)
#112025 (comment)

[davidwrighton]

@am11, about the calls to VirtualUnwind ... well, we could replace them by doing something with the TransitionBlock, but it would be a lot of processor specific bespoke code that would be easy to break. Until there is a perf issue, I'd like to just use the VirtualUnwind.

[davidwrighton]

/azp run runtime-jit-experimental

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

We like to mark methods that are only used within the file as static

[jkotas]

/azp run runtime-jit-experimental

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

LGTM. Thank you!

[jkotas]

/azp run runtime-jit-experimental

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).