JIT should recognize and optimize "try / catch (OverflowException)" patterns

[GrabYourPitchforks]

Based on discussion at #46259 (comment).

Basically, there are some scenarios where we want to trap arithmetic overflow and execute a different code path, but we don't necessarily want to treat this as a failure per se, and we don't want the expensive exception dispatch logic that accompanies standard checked arithmetic.

One example is in implementations of BigInteger-like types, where we want to know if a carry occurred so that we can flow it to the next element in the chain. We anticipate this occurring with decent regularity, so we don't want it to be treated as a one-off or error case.

uint[] left; // assume all are little-endian and the same length
uint[] right;
uint[] result;
int carry = 0;

for (int i = 0; i < left.Length; i++)
{
    try { result[i] = checked(left[i] + right[i] + carry); carry = 0; }
    catch (OverflowException) { result[i] = left[i] + right[i] + carry; carry = 1; }
}

This might be a bit weird to implement, as there would naturally be open questions about what happens if a debugger is attached (since no exception is dispatched), what happens to any registered exception filters, and so on. But per the linked issue, this might be preferable to adding specialized "please tell me if overflow occurred but don't fail" APIs across our numerics namespaces.

/cc @tannergooding @jkotas

category:cq
theme:eh

[tannergooding]

My main concern here is how usable this will be.

try { } catch { } isn't necessarily "intuitive" nor easily inlineable into other expressions. I imagine most users who need this may end up creating a wrapper method for this scenario

[Wraith2]

Or, there should be a way to do that operation without an exception. I believe that would involve exposing flags which has been mentioned.

[jkotas]

My suggestion for intrisicifying try/catch of overflow exceptions was reaction to "Disable overflow exceptions per-thread at runtime?" idea. The scenario for that is that you have relatively complex expression and you want to know whether an overflow occured somewhere inside that expression. You are not interested in knowing about where exactly and by how much.

It is different from the big integer add scenario where the expression is simple and you want to know the exact result. That can be either peephole optimization on top of the current canonical pattern like what some C/C++ compilers have today: https://godbolt.org/z/f8z7TG51o . Or it can be an intrinsic public API to make it explicit like what some other C/C++ compilers have.

[acaly]

I have had a similar issue. I think for the original use case, it would be better to provide an intrinsic (add with carry), and expect the JIT to optimize for you, instead of catching the Exception.

The reason is, if you only end up with a "whether" without knowing exactly "where", you probably have to do the entire calculation again, with a non-overflowing method. If this overflow is common enough, then you will not get much performance gain compaired with simply doing everything without overflowing (as what is done today in BigInt).

When I had that issue, I finally chose to use C++ for some heavy calculation and call from C#. The C++ compiler is also able to optimize much more aggresively. Though obvirously it will make cross-platform more difficult.

[jkotas]

I finally chose to use C++ for some heavy calculation

@acaly Have you used any special C++ compiler intrinsics to perform these heavy calculations? If yes, do you have any numbers for how much you gained by using these intrinsics?

[acaly]

@jkotas

Yes. Specifically, addcarry and lzcnt. The latter is not quite related. In the addcarry case I have one function that adds four uint32 (i.e., uint128) to the lowest bits of a long big int buffer. I only write a generic long add (something like template <std::size_t N> void LongAdd(const std::uint32_t* a, ...)), and the C++ compiler is able to expand that loop (which repeats for 4 times) and generate consecutive ADC instructions. C# currently does not have add with carry and manually maintaining that carry bit seems a lot more work compared with simply using CPU flags.

I don't have a systematic measurement though. If you think that would be helpful I can provide the number.

[AndyAyersMS]

Suggest we move this to future (or close).