Move arithmetic DivideByZero and Overflow exceptions to JIT on 32-bit platforms

[am11]

From @jkotas #109087 (comment)

The extra call frame introduced by the changes in this PR is where the overhead is.

main: managed method -> FCall (with argument checks that require HMF) -> internal C-runtime div helper

PR (notice the extra frame): managed method -> managed helper call (argument checks) -> FCall (without argument checks) -> internal C-runtime div helper

Inlined checks: managed method (with argument checks) -> FCall (without argument checks) -> internal C-runtime div helper

On 32 bit platforms such as x86 and arm32, JIT uses software fallback CORINFO_HELP_{,U,L,UL}{DIV,MOD} to handle DivideByZero and Overflow exceptions in div/mod arithmetic ops via FCThrow in jithelpers.cpp. FCThrow uses HELPER_METHOD_FRAME which we are trying to remove from runtime (#95695).

JIT can handle inserting the software fallback using the existing CORINFO_HELP_OVERFLOW and CORINFO_HELP_THROWDIVZERO helpers on 32 bit platforms. This will remove 8 (out of 9) remaining FCThrow calls from jithelpers.cpp.

[dotnet-policy-service]

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

[jkotas]

@EgorBo Any chance you can take a look at this?

This is contributing to our larger runtime simplification and unifications efforts.

[EgorBo]

@EgorBo Any chance you can take a look at this?

This is contributing to our larger runtime simplification and unifications efforts.

Can we just introduce managed helpers? (with qcalls into native helpers for actual division, or maybe even fully managed).

[MichalPetryka]

@EgorBo Any chance you can take a look at this?
This is contributing to our larger runtime simplification and unifications efforts.

Can we just introduce managed helpers? (with qcalls into native helpers for actual division, or maybe even fully managed).

That's what #109087 tried.

[am11]

@EgorBo I was wondering if we can handle it in JIT itself, like we are checking the conditions here:

https://github.com/dotnet/runtime/blob/afdd68bf7cbd3128e1a86def2d5f9789591a1d2d/src/coreclr/jit/gentree.cpp#L16104-L16110

[EgorBo]

That's what #109087 tried.

Ah, short memory

@EgorBo I was wondering if we can handle it in JIT itself, like we are checking the conditions here:

We can definitely do this in JIT, just turns out to be not entirely single-line change as I hoped 🙂

[EgorBo]

@jkotas @am11 it looks like we need to emit quite a bit of control-flow to re-create what these conditions do https://github.com/am11/runtime/blob/0e61d9d6ca5c312443edf175e7d7b6be72077c00/src/libraries/System.Private.CoreLib/src/System/Math.DivModInt.cs#L55-L78 (4 different helpers + extra helpers on arm32) and there is little we can re-use from existing arm64 impl.

After discussing this with @jakobbotsch, we wonder if we can:

1. Inline managed helpers in JIT (thus, some conditions could be folded or fast path (32bit divison) can be performed without call overhead)
2. Replace FCall with a direct pinvoke (without gc transition) to libc/whatever native helper we end up using?

also, I've kicked off a benchmark on 32bit windows to see performance impact of am11 impl: #109087 (comment)