Move arithmetic helpers to managed code

[am11]

Only the FCThrow ones in jithelpers have been moved. The JIT_GetRefAny method was left out due to the existing TODO regarding type inheritance. (JIT_GetRefAny is handled in #110344)

[jkotas]

We should check the perf impact on the affected architectures to see whether it is something we can live with.

There is alternatives with better perf possible: Inline the exception throwing in the JITed code (and optimize it out if the JIT can prove that it cannot happen). We do that on arm64 today.

[am11]

@AaronRobinsonMSFT, win-x86 leg is failing this assert:

Assert failure(PID 2788 [0x00000ae4], Thread: 3704 [0x0e78]): CONTRACT VIOLATION by CreateCOMPlusExceptionObject at "D:\a\_work\1\s\src\coreclr\vm\excep.cpp":5725

GC_TRIGGERS encountered in a GC_NOTRIGGER scope

                        CONTRACT in CreateCOMPlusExceptionObject at "D:\a\_work\1\s\src\coreclr\vm\excep.cpp":5725
                        CONTRACT in MethodDescCallSite::CallTargetWorker at "D:\a\_work\1\s\src\coreclr\vm\callhelpers.cpp":307
                        GCX_COOP in Assembly::ExecuteMainMethod at "D:\a\_work\1\s\src\coreclr\vm\assembly.cpp":1380
                        CONTRACT in Assembly::ExecuteMainMethod at "D:\a\_work\1\s\src\coreclr\vm\assembly.cpp":1366
                        GCX_COOP in CorHost2::ExecuteAssembly at "D:\a\_work\1\s\src\coreclr\vm\corhost.cpp":329
                        CONTRACT in CorHost2::ExecuteAssembly at "D:\a\_work\1\s\src\coreclr\vm\corhost.cpp":269

Does it mean we need to use something like FC_GC_POLL_RET besides FCALL_CONTRACT?

[jkotas]

Does it mean we need to use something like FC_GC_POLL_RET

FC_GC_POLL_RET expands to HMF. It would not be an improvement.

I think the crash that you are seeing is caused by calling convention mismatch for 64-bit helpers. The existing helpers use VV flavor of the FCall macros, but your new helpers do not.

The existing NAOT implementation deals with the calling convention issues with using QCalls that use standard calling convention instead of managed calling convention.

[am11]

Software fallback impl was much worse: diff to base ratio is 61.50 vs. 1.58 with the FCall.

[am11]

@EgorBot -windows_intel -use32bit

using BenchmarkDotNet.Attributes;

public class Bench
{
    long a = 10000000000000000L;
    long b = 1000L;

    [Benchmark]
    public long SDiv() => a / b;
}

[am11]

Software fallback impl was much worse: diff to base ratio is 61.50 vs. 1.58 with the FCall.

With QCall+COMPlusThrow approach (f0cd111), it's 2.91. 🥲

[am11]

This is blocked until that half nanoseconds regression on x86 is sorted out on JIT side. Lets revisit this when that happens.