Note regarding thenew-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

CC. @dotnet/jit-contrib for the JIT side.

This is one of the few remaining cases that should need JIT side work, most of the remaining APIs in#93513 will be implemented purely in managed code. The*Estimate APIs are special as they need to work in the face of R2R due to being intentionally non-deterministic across hardware andFusedMultiplyAdd represents a case that optimizes down to a single instruction and which is a core part of many already deeply complex algorithms, so the benefits of guaranteeing expansion make it good to hook up to the existing intrinsic support.

CC. @dotnet/jit-contrib for the JIT side.

This is one of the few remaining cases that should need JIT side work, most of the remaining APIs in#93513 will be implemented purely in managed code. The*Estimate APIs are special as they need to work in the face of R2R due to being intentionally non-deterministic across hardware andFusedMultiplyAdd represents a case that optimizes down to a single instruction and which is a core part of many already deeply complex algorithms, so the benefits of guaranteeing expansion make it good to hook up to the existing intrinsic support.

Should we rather introduce a new attribute to prevent methods from being pre-jitted (and inlined into pre-jitted code)?

Should we rather introduce a new attribute to prevent methods from being pre-jitted (and inlined into pre-jitted code)?

We technically have one already, it'sBypassReadyToRun (but we don't define or use it anyways as it was a legacy attribute for Crossgen1). The PR where I fixed this forMath.ReciprocalSqrtEstimate it was suggested to do it this other way instead.

I'm also not sure the number of*Estimate APIs is at the point where it's beneficial to define and expose that attribute and there's various other quirks that may need to be considered/solved in that scenario was well, plus the general consideration that some of these APIs are known to be used in hot paths of complex algorithms where inlining can fail, even with the inlining boost that methods using intrinsics get.

-- I do want to get to a point, someday, where we can move a lot of complexity out of the JIT and into the BCL instead. Ideally just the platform specific intrinsics and core xplat APIs which were exposed instead of platform specific APIs (likeCreate) are handled in the JIT and things likeVector2/3/4 orVector128.WidenLower and APIs like that are handled entirely in managed code instead. I just don't think we're at that point yet today and need more work in the inliner and other places to ensure that we can get the desired codegen.

CC.@stephentoub for the libraries side.

The one thing to note is that given howTensorPrimitives definesMultiplyAddEstimate and uses it in other APIs, the API was moved down toINumberBase<T> rather than being put onIFloatingPointIeee754<T>. This is still sensible for other types, it just always does the naive thing and isn't exposed as a member that's accessible from non-generic contexts.

-- I do want to get to a point, someday, where we can move a lot of complexity out of the JIT and into the BCL instead. Ideally just the platform specific intrinsics and core xplat APIs which were exposed instead of platform specific APIs (like Create) are handled in the JIT and things like Vector2/3/4 or Vector128.WidenLower and APIs like that are handled entirely in managed code instead. I just don't think we're at that point yet today and need more work in the inliner and other places to ensure that we can get the desired codegen.

I've logged#102275 to track prototyping this work and seeing if we can identify some of the places that are still preventing it from happening.

This seems like a good thing to try and do around the time .NET 9 RC1 snaps and we have a bit of a small break before .NET 10 work really gets going.