Ensure Log2 can actually be imported as intrinsic

[tannergooding]

Previously this was code was never being hit because we were checking against the non-precise var_type and so we always saw TYP_INT even for unsigned inputs. Now we correctly handle checking for unsigned inputs and allow importing signed ones as well.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the CoreCLR JIT importer for the NI_PRIMITIVE_Log2 primitive intrinsic to correctly distinguish signed vs. unsigned inputs using the precise type, enabling the intrinsic expansion for unsigned arguments and adding a conditional throw path for signed arguments.

Changes:

• Fixes signed/unsigned detection for Log2 by using JitType2PreciseVarType(baseJitType) rather than the non-precise baseType.
• Implements the Log2 expansion via LeadingZeroCount(value | 1) to satisfy the 0 -> 0 contract.
• Adds a conditional throw for negative signed inputs using a qmark-based fallback path.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[EgorBo]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK) and move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

The diffs here are significant. We see -321k bytes of codegen on Linux Arm64

Literally 99% of diffs are in libraries_tests.run. and all example diffs imply that

[Intrinsic]publicstaticuintLog2(uintvalue)=>(uint)BitOperations.Log2(value);

is not inlined. I suspect it might be either PGO-driven or it needs an AggressiveInlining.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

or just slap AggressiveInlining everywhere

cc @dotnet/jit-contrib for opinions

[tannergooding]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK)

I am doubtful that QMARK will ever fully go away as they have a significant benefit in that they allow introducing block like functionality (namely a compare + branch to throw an exception) into the code. If anything, it will just be replaced with a helper that does the creation of the if/else blocks at the point you're currently creating the QMARK node instead. They exist because it simplifies a bit of handling in the early phases and even allows some constant folding without forcing the block to actually be produced.

move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

Most compilers do this for the fundamental math APIs like this, we're not special and even have stricter timing requirements which means there is more reason for us to handle such APIs intrinsically as it significantly reduces the amount of work the JIT has to do. The inliner is always going to have limitations and there's no reason to contribute to its pessimizations for these foundational APIs everything else is built on.

Literally 99% of diffs are in libraries_tests.run.

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others. That's why I explicitly called out the hits we also have in other areas. But that's also representative of this code being "hot" and common to code that most apps and binaries end up using, even if indirectly.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

I don't think this is a fix and it just pushes things down the road more.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000:ldarg.0IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)IL_0006: ret

But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't. We skip all those checks, all the eating of the budget, and all the expensive handling by treating these key APIs as intrinsic. It completely bypasses the other expensive transforms and checks which ultimately simplifies what the JIT has to do, by adding a few lines to the importer to handle the known special scenarios.

[EgorBo]

I am doubtful that QMARK will ever fully go away as they have a significant benefit

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

The inliner is always going to have limitations

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users? I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about. Are you going to continue pushing various small methods as JIT intrinsics?

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

I do think we need to stop using it as an excuse. I agree on importing things as special opcodes so then JIT can emit those opcodes as part of other transformations and rely on proper expansion - that made sense to me, but it's no the case here as we just mimic inliner's work, not more than that.
Another downside of all of these intrinsics is that we continue adding binary size to jit while the original C# code can be trimmed.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000: ldarg.0
IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)
IL_0006: ret
But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't

I think we need to study why we give up, it might be something fundamental like abstract generic resolution in importer.
Or you just copied a diff from Tier0 that is not inlined. What is the Tier1 method we should look at?

[tannergooding]

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

My point here was rather that we have a fundamental need to introduce IR that represents x = cond ? throw : y and right now that is handled via QMARK. Even if we remove QMARK, it will just have to be replaced by something else that puts in the relevant blocks directly instead.

So even if they aren't the best IR today, the code is logically correct and will maintain roughly the current shape even when QMARKs disappear.

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users?

Because intrinsifying everything is both impossible and a negative. Most methods are not foundational in that sense and it would effectively cause "too much inlining", regress throughput, regress codegen size, etc.

Log2 is such a foundational helper, it and many of the APIs on the primitive types are the building blocks for all the other algorithms. It is an API that most compilers explicitly recognize and handle as intrinsic in some fashion, accordingly.

I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about.

I agree, but we also know this is much more complex work and that it will always have limits. So for foundational cases that are common to other compilers and where we can avoid some of the redundant work, it makes sense.

Are you going to continue pushing various small methods as JIT intrinsics?

The short answer is not really, fixing the existing Log2 handling really rounds out the set of them.

I'm not and have never been looking to intrinsify the world, only the key foundational math APIs like this one, i.e. the building blocks for the rest of .NET. Most of these were already handled and Log2 was one where we notably had handling but it was never firing because we were only checking TYP_INT and not TYP_UINT.

Of the foundational math APIs that aren't intrinsified, we only have integral Abs, Log10, Max, and Min. However, these likely aren't ever going to get handling because they aren't common to other compilers, don't have trivial hardware acceleration available, or do not have the size/ir complexity that other intrinsics have.

At best we might consider having Max/Min directly import as GT_CONDITIONAL to save on inlining and converting to those anyways, but then we really need the JIT to have better GT_CONDITIONAL support in the first place and because there isn't the size/ir complexity that other APIs have and we also want DPGO to work, I find it much less likely we do that.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

Does the FullOpts metric include T0? If it does we should probably split that out so we can actually differentiate MinOpts vs T0 vs T1 vs FullOpts, I had assumed it was just T1+FullOpts

I had downloaded the full diffs and saw most of the impactful changes in code that was actually proper fullopts or T1, i.e. the asmdiff says ; FullOpts code

One of the more robust cases is:

- ; 93 inlinees with PGO data; 314 single block inlinees; 54 inlinees without PGO data
+ ; 41 inlinees with PGO data; 85 single block inlinees; 11 inlinees without PGO data

going from 611 locals with a frame size of 632 down to 243 locals with a frame size of 104 and from 10112 bytes of codegen down to 1847 bytes of codegen

But for non tests it improves the codegen around string formatting for all integer primitives (via CountDigits and CountHexDigits), array sorting and the various Sorted* collections, some BigInteger handling particularly around ModPow, etc

This is also why there are so many triggers in tests, because Log2 is used in APIs that most apps, even trivial ones, end up using, so it triggers for a lot of code.

[EgorBo]

Leaving this up to you, I am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it. I understand that the debugging experience is worse in optimized code but I believe we've never changed the content of the exception before based on opts.

[tannergooding]

am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it

CC. @jkotas for input on this bit. The consideration is essentially whether it is okay for T1 (optimized) codegen for Log2 to differ in the message included as part of ArgumentOutOfRangeException from T0 (unoptimized/debug/t0) codegen?

I don't feel its worth complicating the JIT/VM to support preserving that message (ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_NeedNonNegNum) in the actual JIT throw helper support and it is okay for T1 code to differ here, particularly since its the only exception for this API.

The alternatives would be:

• Also drop the info from the exception in the managed fallback path
• Instead of producing a gtNewMustThrowException node, keep a second Log2 intrinsic and use the existing rationalization rewriting support to force it back to a call (this loses info that it definitively throws and is cold, which can be added is just a bit more complex)

---

Leaving this up to you

As for the overall change @EgorBo, I do think its worth it today and plan on taking it. We know Log2 is a building block API and had already had the rest of the foundational support here, it is very rare we get a change where the diffs (-321k bytes) and TP (-0.30% instructions retired) improvement are so definitively good (including both tests and some key production code methods, such as the primitive formatting/parsing helpers).

I also do understand the desire to handle these scenarios more generally via the inliner, but that's not going to happen today or even this release. I am more than happy to see us drop such JIT support in the future when the inliner is capable of handling it, the same as we've done with other intrinsic functionality (such as when we finally dropped the direct support for S.N.Vector2/3/4, Quaternion, Plane, etc).

[jkotas]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

[tannergooding]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

I'll see the diffs around the second alternative I gave then, carrying the throw path through as the rewritable intrinsic so it forces it back to the managed path in that case and preserves the exception.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[tannergooding]

Previously this was code was never being hit because we were checking against the non-precise var_type and so we always saw TYP_INT even for unsigned inputs. Now we correctly handle checking for unsigned inputs and allow importing signed ones as well.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the CoreCLR JIT importer for the NI_PRIMITIVE_Log2 primitive intrinsic to correctly distinguish signed vs. unsigned inputs using the precise type, enabling the intrinsic expansion for unsigned arguments and adding a conditional throw path for signed arguments.

Changes:

• Fixes signed/unsigned detection for Log2 by using JitType2PreciseVarType(baseJitType) rather than the non-precise baseType.
• Implements the Log2 expansion via LeadingZeroCount(value | 1) to satisfy the 0 -> 0 contract.
• Adds a conditional throw for negative signed inputs using a qmark-based fallback path.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[EgorBo]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK) and move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

The diffs here are significant. We see -321k bytes of codegen on Linux Arm64

Literally 99% of diffs are in libraries_tests.run. and all example diffs imply that

[Intrinsic]publicstaticuintLog2(uintvalue)=>(uint)BitOperations.Log2(value);

is not inlined. I suspect it might be either PGO-driven or it needs an AggressiveInlining.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

or just slap AggressiveInlining everywhere

cc @dotnet/jit-contrib for opinions

[tannergooding]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK)

I am doubtful that QMARK will ever fully go away as they have a significant benefit in that they allow introducing block like functionality (namely a compare + branch to throw an exception) into the code. If anything, it will just be replaced with a helper that does the creation of the if/else blocks at the point you're currently creating the QMARK node instead. They exist because it simplifies a bit of handling in the early phases and even allows some constant folding without forcing the block to actually be produced.

move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

Most compilers do this for the fundamental math APIs like this, we're not special and even have stricter timing requirements which means there is more reason for us to handle such APIs intrinsically as it significantly reduces the amount of work the JIT has to do. The inliner is always going to have limitations and there's no reason to contribute to its pessimizations for these foundational APIs everything else is built on.

Literally 99% of diffs are in libraries_tests.run.

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others. That's why I explicitly called out the hits we also have in other areas. But that's also representative of this code being "hot" and common to code that most apps and binaries end up using, even if indirectly.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

I don't think this is a fix and it just pushes things down the road more.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000:ldarg.0IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)IL_0006: ret

But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't. We skip all those checks, all the eating of the budget, and all the expensive handling by treating these key APIs as intrinsic. It completely bypasses the other expensive transforms and checks which ultimately simplifies what the JIT has to do, by adding a few lines to the importer to handle the known special scenarios.

[EgorBo]

I am doubtful that QMARK will ever fully go away as they have a significant benefit

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

The inliner is always going to have limitations

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users? I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about. Are you going to continue pushing various small methods as JIT intrinsics?

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

I do think we need to stop using it as an excuse. I agree on importing things as special opcodes so then JIT can emit those opcodes as part of other transformations and rely on proper expansion - that made sense to me, but it's no the case here as we just mimic inliner's work, not more than that.
Another downside of all of these intrinsics is that we continue adding binary size to jit while the original C# code can be trimmed.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000: ldarg.0
IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)
IL_0006: ret
But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't

I think we need to study why we give up, it might be something fundamental like abstract generic resolution in importer.
Or you just copied a diff from Tier0 that is not inlined. What is the Tier1 method we should look at?

[tannergooding]

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

My point here was rather that we have a fundamental need to introduce IR that represents x = cond ? throw : y and right now that is handled via QMARK. Even if we remove QMARK, it will just have to be replaced by something else that puts in the relevant blocks directly instead.

So even if they aren't the best IR today, the code is logically correct and will maintain roughly the current shape even when QMARKs disappear.

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users?

Because intrinsifying everything is both impossible and a negative. Most methods are not foundational in that sense and it would effectively cause "too much inlining", regress throughput, regress codegen size, etc.

Log2 is such a foundational helper, it and many of the APIs on the primitive types are the building blocks for all the other algorithms. It is an API that most compilers explicitly recognize and handle as intrinsic in some fashion, accordingly.

I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about.

I agree, but we also know this is much more complex work and that it will always have limits. So for foundational cases that are common to other compilers and where we can avoid some of the redundant work, it makes sense.

Are you going to continue pushing various small methods as JIT intrinsics?

The short answer is not really, fixing the existing Log2 handling really rounds out the set of them.

I'm not and have never been looking to intrinsify the world, only the key foundational math APIs like this one, i.e. the building blocks for the rest of .NET. Most of these were already handled and Log2 was one where we notably had handling but it was never firing because we were only checking TYP_INT and not TYP_UINT.

Of the foundational math APIs that aren't intrinsified, we only have integral Abs, Log10, Max, and Min. However, these likely aren't ever going to get handling because they aren't common to other compilers, don't have trivial hardware acceleration available, or do not have the size/ir complexity that other intrinsics have.

At best we might consider having Max/Min directly import as GT_CONDITIONAL to save on inlining and converting to those anyways, but then we really need the JIT to have better GT_CONDITIONAL support in the first place and because there isn't the size/ir complexity that other APIs have and we also want DPGO to work, I find it much less likely we do that.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

Does the FullOpts metric include T0? If it does we should probably split that out so we can actually differentiate MinOpts vs T0 vs T1 vs FullOpts, I had assumed it was just T1+FullOpts

I had downloaded the full diffs and saw most of the impactful changes in code that was actually proper fullopts or T1, i.e. the asmdiff says ; FullOpts code

One of the more robust cases is:

- ; 93 inlinees with PGO data; 314 single block inlinees; 54 inlinees without PGO data
+ ; 41 inlinees with PGO data; 85 single block inlinees; 11 inlinees without PGO data

going from 611 locals with a frame size of 632 down to 243 locals with a frame size of 104 and from 10112 bytes of codegen down to 1847 bytes of codegen

But for non tests it improves the codegen around string formatting for all integer primitives (via CountDigits and CountHexDigits), array sorting and the various Sorted* collections, some BigInteger handling particularly around ModPow, etc

This is also why there are so many triggers in tests, because Log2 is used in APIs that most apps, even trivial ones, end up using, so it triggers for a lot of code.

[EgorBo]

Leaving this up to you, I am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it. I understand that the debugging experience is worse in optimized code but I believe we've never changed the content of the exception before based on opts.

[tannergooding]

am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it

CC. @jkotas for input on this bit. The consideration is essentially whether it is okay for T1 (optimized) codegen for Log2 to differ in the message included as part of ArgumentOutOfRangeException from T0 (unoptimized/debug/t0) codegen?

I don't feel its worth complicating the JIT/VM to support preserving that message (ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_NeedNonNegNum) in the actual JIT throw helper support and it is okay for T1 code to differ here, particularly since its the only exception for this API.

The alternatives would be:

• Also drop the info from the exception in the managed fallback path
• Instead of producing a gtNewMustThrowException node, keep a second Log2 intrinsic and use the existing rationalization rewriting support to force it back to a call (this loses info that it definitively throws and is cold, which can be added is just a bit more complex)

---

Leaving this up to you

As for the overall change @EgorBo, I do think its worth it today and plan on taking it. We know Log2 is a building block API and had already had the rest of the foundational support here, it is very rare we get a change where the diffs (-321k bytes) and TP (-0.30% instructions retired) improvement are so definitively good (including both tests and some key production code methods, such as the primitive formatting/parsing helpers).

I also do understand the desire to handle these scenarios more generally via the inliner, but that's not going to happen today or even this release. I am more than happy to see us drop such JIT support in the future when the inliner is capable of handling it, the same as we've done with other intrinsic functionality (such as when we finally dropped the direct support for S.N.Vector2/3/4, Quaternion, Plane, etc).

[jkotas]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

[tannergooding]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

I'll see the diffs around the second alternative I gave then, carrying the throw path through as the rewritable intrinsic so it forces it back to the managed path in that case and preserves the exception.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[tannergooding]

Previously this was code was never being hit because we were checking against the non-precise var_type and so we always saw TYP_INT even for unsigned inputs. Now we correctly handle checking for unsigned inputs and allow importing signed ones as well.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the CoreCLR JIT importer for the NI_PRIMITIVE_Log2 primitive intrinsic to correctly distinguish signed vs. unsigned inputs using the precise type, enabling the intrinsic expansion for unsigned arguments and adding a conditional throw path for signed arguments.

Changes:

• Fixes signed/unsigned detection for Log2 by using JitType2PreciseVarType(baseJitType) rather than the non-precise baseType.
• Implements the Log2 expansion via LeadingZeroCount(value | 1) to satisfy the 0 -> 0 contract.
• Adds a conditional throw for negative signed inputs using a qmark-based fallback path.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[EgorBo]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK) and move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

The diffs here are significant. We see -321k bytes of codegen on Linux Arm64

Literally 99% of diffs are in libraries_tests.run. and all example diffs imply that

[Intrinsic]publicstaticuintLog2(uintvalue)=>(uint)BitOperations.Log2(value);

is not inlined. I suspect it might be either PGO-driven or it needs an AggressiveInlining.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

or just slap AggressiveInlining everywhere

cc @dotnet/jit-contrib for opinions

[tannergooding]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK)

I am doubtful that QMARK will ever fully go away as they have a significant benefit in that they allow introducing block like functionality (namely a compare + branch to throw an exception) into the code. If anything, it will just be replaced with a helper that does the creation of the if/else blocks at the point you're currently creating the QMARK node instead. They exist because it simplifies a bit of handling in the early phases and even allows some constant folding without forcing the block to actually be produced.

move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

Most compilers do this for the fundamental math APIs like this, we're not special and even have stricter timing requirements which means there is more reason for us to handle such APIs intrinsically as it significantly reduces the amount of work the JIT has to do. The inliner is always going to have limitations and there's no reason to contribute to its pessimizations for these foundational APIs everything else is built on.

Literally 99% of diffs are in libraries_tests.run.

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others. That's why I explicitly called out the hits we also have in other areas. But that's also representative of this code being "hot" and common to code that most apps and binaries end up using, even if indirectly.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

I don't think this is a fix and it just pushes things down the road more.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000:ldarg.0IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)IL_0006: ret

But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't. We skip all those checks, all the eating of the budget, and all the expensive handling by treating these key APIs as intrinsic. It completely bypasses the other expensive transforms and checks which ultimately simplifies what the JIT has to do, by adding a few lines to the importer to handle the known special scenarios.

[EgorBo]

I am doubtful that QMARK will ever fully go away as they have a significant benefit

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

The inliner is always going to have limitations

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users? I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about. Are you going to continue pushing various small methods as JIT intrinsics?

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

I do think we need to stop using it as an excuse. I agree on importing things as special opcodes so then JIT can emit those opcodes as part of other transformations and rely on proper expansion - that made sense to me, but it's no the case here as we just mimic inliner's work, not more than that.
Another downside of all of these intrinsics is that we continue adding binary size to jit while the original C# code can be trimmed.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000: ldarg.0
IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)
IL_0006: ret
But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't

I think we need to study why we give up, it might be something fundamental like abstract generic resolution in importer.
Or you just copied a diff from Tier0 that is not inlined. What is the Tier1 method we should look at?

[tannergooding]

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

My point here was rather that we have a fundamental need to introduce IR that represents x = cond ? throw : y and right now that is handled via QMARK. Even if we remove QMARK, it will just have to be replaced by something else that puts in the relevant blocks directly instead.

So even if they aren't the best IR today, the code is logically correct and will maintain roughly the current shape even when QMARKs disappear.

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users?

Because intrinsifying everything is both impossible and a negative. Most methods are not foundational in that sense and it would effectively cause "too much inlining", regress throughput, regress codegen size, etc.

Log2 is such a foundational helper, it and many of the APIs on the primitive types are the building blocks for all the other algorithms. It is an API that most compilers explicitly recognize and handle as intrinsic in some fashion, accordingly.

I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about.

I agree, but we also know this is much more complex work and that it will always have limits. So for foundational cases that are common to other compilers and where we can avoid some of the redundant work, it makes sense.

Are you going to continue pushing various small methods as JIT intrinsics?

The short answer is not really, fixing the existing Log2 handling really rounds out the set of them.

I'm not and have never been looking to intrinsify the world, only the key foundational math APIs like this one, i.e. the building blocks for the rest of .NET. Most of these were already handled and Log2 was one where we notably had handling but it was never firing because we were only checking TYP_INT and not TYP_UINT.

Of the foundational math APIs that aren't intrinsified, we only have integral Abs, Log10, Max, and Min. However, these likely aren't ever going to get handling because they aren't common to other compilers, don't have trivial hardware acceleration available, or do not have the size/ir complexity that other intrinsics have.

At best we might consider having Max/Min directly import as GT_CONDITIONAL to save on inlining and converting to those anyways, but then we really need the JIT to have better GT_CONDITIONAL support in the first place and because there isn't the size/ir complexity that other APIs have and we also want DPGO to work, I find it much less likely we do that.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

Does the FullOpts metric include T0? If it does we should probably split that out so we can actually differentiate MinOpts vs T0 vs T1 vs FullOpts, I had assumed it was just T1+FullOpts

I had downloaded the full diffs and saw most of the impactful changes in code that was actually proper fullopts or T1, i.e. the asmdiff says ; FullOpts code

One of the more robust cases is:

- ; 93 inlinees with PGO data; 314 single block inlinees; 54 inlinees without PGO data
+ ; 41 inlinees with PGO data; 85 single block inlinees; 11 inlinees without PGO data

going from 611 locals with a frame size of 632 down to 243 locals with a frame size of 104 and from 10112 bytes of codegen down to 1847 bytes of codegen

But for non tests it improves the codegen around string formatting for all integer primitives (via CountDigits and CountHexDigits), array sorting and the various Sorted* collections, some BigInteger handling particularly around ModPow, etc

This is also why there are so many triggers in tests, because Log2 is used in APIs that most apps, even trivial ones, end up using, so it triggers for a lot of code.

[EgorBo]

Leaving this up to you, I am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it. I understand that the debugging experience is worse in optimized code but I believe we've never changed the content of the exception before based on opts.

[tannergooding]

am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it

CC. @jkotas for input on this bit. The consideration is essentially whether it is okay for T1 (optimized) codegen for Log2 to differ in the message included as part of ArgumentOutOfRangeException from T0 (unoptimized/debug/t0) codegen?

I don't feel its worth complicating the JIT/VM to support preserving that message (ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_NeedNonNegNum) in the actual JIT throw helper support and it is okay for T1 code to differ here, particularly since its the only exception for this API.

The alternatives would be:

• Also drop the info from the exception in the managed fallback path
• Instead of producing a gtNewMustThrowException node, keep a second Log2 intrinsic and use the existing rationalization rewriting support to force it back to a call (this loses info that it definitively throws and is cold, which can be added is just a bit more complex)

---

Leaving this up to you

As for the overall change @EgorBo, I do think its worth it today and plan on taking it. We know Log2 is a building block API and had already had the rest of the foundational support here, it is very rare we get a change where the diffs (-321k bytes) and TP (-0.30% instructions retired) improvement are so definitively good (including both tests and some key production code methods, such as the primitive formatting/parsing helpers).

I also do understand the desire to handle these scenarios more generally via the inliner, but that's not going to happen today or even this release. I am more than happy to see us drop such JIT support in the future when the inliner is capable of handling it, the same as we've done with other intrinsic functionality (such as when we finally dropped the direct support for S.N.Vector2/3/4, Quaternion, Plane, etc).

[jkotas]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

[tannergooding]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

I'll see the diffs around the second alternative I gave then, carrying the throw path through as the rewritable intrinsic so it forces it back to the managed path in that case and preserves the exception.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[tannergooding]

Previously this was code was never being hit because we were checking against the non-precise var_type and so we always saw TYP_INT even for unsigned inputs. Now we correctly handle checking for unsigned inputs and allow importing signed ones as well.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the CoreCLR JIT importer for the NI_PRIMITIVE_Log2 primitive intrinsic to correctly distinguish signed vs. unsigned inputs using the precise type, enabling the intrinsic expansion for unsigned arguments and adding a conditional throw path for signed arguments.

Changes:

• Fixes signed/unsigned detection for Log2 by using JitType2PreciseVarType(baseJitType) rather than the non-precise baseType.
• Implements the Log2 expansion via LeadingZeroCount(value | 1) to satisfy the 0 -> 0 contract.
• Adds a conditional throw for negative signed inputs using a qmark-based fallback path.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[EgorBo]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK) and move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

The diffs here are significant. We see -321k bytes of codegen on Linux Arm64

Literally 99% of diffs are in libraries_tests.run. and all example diffs imply that

[Intrinsic]publicstaticuintLog2(uintvalue)=>(uint)BitOperations.Log2(value);

is not inlined. I suspect it might be either PGO-driven or it needs an AggressiveInlining.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

or just slap AggressiveInlining everywhere

cc @dotnet/jit-contrib for opinions

[tannergooding]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK)

I am doubtful that QMARK will ever fully go away as they have a significant benefit in that they allow introducing block like functionality (namely a compare + branch to throw an exception) into the code. If anything, it will just be replaced with a helper that does the creation of the if/else blocks at the point you're currently creating the QMARK node instead. They exist because it simplifies a bit of handling in the early phases and even allows some constant folding without forcing the block to actually be produced.

move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

Most compilers do this for the fundamental math APIs like this, we're not special and even have stricter timing requirements which means there is more reason for us to handle such APIs intrinsically as it significantly reduces the amount of work the JIT has to do. The inliner is always going to have limitations and there's no reason to contribute to its pessimizations for these foundational APIs everything else is built on.

Literally 99% of diffs are in libraries_tests.run.

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others. That's why I explicitly called out the hits we also have in other areas. But that's also representative of this code being "hot" and common to code that most apps and binaries end up using, even if indirectly.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

I don't think this is a fix and it just pushes things down the road more.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000:ldarg.0IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)IL_0006: ret

But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't. We skip all those checks, all the eating of the budget, and all the expensive handling by treating these key APIs as intrinsic. It completely bypasses the other expensive transforms and checks which ultimately simplifies what the JIT has to do, by adding a few lines to the importer to handle the known special scenarios.

[EgorBo]

I am doubtful that QMARK will ever fully go away as they have a significant benefit

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

The inliner is always going to have limitations

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users? I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about. Are you going to continue pushing various small methods as JIT intrinsics?

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

I do think we need to stop using it as an excuse. I agree on importing things as special opcodes so then JIT can emit those opcodes as part of other transformations and rely on proper expansion - that made sense to me, but it's no the case here as we just mimic inliner's work, not more than that.
Another downside of all of these intrinsics is that we continue adding binary size to jit while the original C# code can be trimmed.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000: ldarg.0
IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)
IL_0006: ret
But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't

I think we need to study why we give up, it might be something fundamental like abstract generic resolution in importer.
Or you just copied a diff from Tier0 that is not inlined. What is the Tier1 method we should look at?

[tannergooding]

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

My point here was rather that we have a fundamental need to introduce IR that represents x = cond ? throw : y and right now that is handled via QMARK. Even if we remove QMARK, it will just have to be replaced by something else that puts in the relevant blocks directly instead.

So even if they aren't the best IR today, the code is logically correct and will maintain roughly the current shape even when QMARKs disappear.

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users?

Because intrinsifying everything is both impossible and a negative. Most methods are not foundational in that sense and it would effectively cause "too much inlining", regress throughput, regress codegen size, etc.

Log2 is such a foundational helper, it and many of the APIs on the primitive types are the building blocks for all the other algorithms. It is an API that most compilers explicitly recognize and handle as intrinsic in some fashion, accordingly.

I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about.

I agree, but we also know this is much more complex work and that it will always have limits. So for foundational cases that are common to other compilers and where we can avoid some of the redundant work, it makes sense.

Are you going to continue pushing various small methods as JIT intrinsics?

The short answer is not really, fixing the existing Log2 handling really rounds out the set of them.

I'm not and have never been looking to intrinsify the world, only the key foundational math APIs like this one, i.e. the building blocks for the rest of .NET. Most of these were already handled and Log2 was one where we notably had handling but it was never firing because we were only checking TYP_INT and not TYP_UINT.

Of the foundational math APIs that aren't intrinsified, we only have integral Abs, Log10, Max, and Min. However, these likely aren't ever going to get handling because they aren't common to other compilers, don't have trivial hardware acceleration available, or do not have the size/ir complexity that other intrinsics have.

At best we might consider having Max/Min directly import as GT_CONDITIONAL to save on inlining and converting to those anyways, but then we really need the JIT to have better GT_CONDITIONAL support in the first place and because there isn't the size/ir complexity that other APIs have and we also want DPGO to work, I find it much less likely we do that.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

Does the FullOpts metric include T0? If it does we should probably split that out so we can actually differentiate MinOpts vs T0 vs T1 vs FullOpts, I had assumed it was just T1+FullOpts

I had downloaded the full diffs and saw most of the impactful changes in code that was actually proper fullopts or T1, i.e. the asmdiff says ; FullOpts code

One of the more robust cases is:

- ; 93 inlinees with PGO data; 314 single block inlinees; 54 inlinees without PGO data
+ ; 41 inlinees with PGO data; 85 single block inlinees; 11 inlinees without PGO data

going from 611 locals with a frame size of 632 down to 243 locals with a frame size of 104 and from 10112 bytes of codegen down to 1847 bytes of codegen

But for non tests it improves the codegen around string formatting for all integer primitives (via CountDigits and CountHexDigits), array sorting and the various Sorted* collections, some BigInteger handling particularly around ModPow, etc

This is also why there are so many triggers in tests, because Log2 is used in APIs that most apps, even trivial ones, end up using, so it triggers for a lot of code.

[EgorBo]

Leaving this up to you, I am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it. I understand that the debugging experience is worse in optimized code but I believe we've never changed the content of the exception before based on opts.

[tannergooding]

am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it

CC. @jkotas for input on this bit. The consideration is essentially whether it is okay for T1 (optimized) codegen for Log2 to differ in the message included as part of ArgumentOutOfRangeException from T0 (unoptimized/debug/t0) codegen?

I don't feel its worth complicating the JIT/VM to support preserving that message (ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_NeedNonNegNum) in the actual JIT throw helper support and it is okay for T1 code to differ here, particularly since its the only exception for this API.

The alternatives would be:

• Also drop the info from the exception in the managed fallback path
• Instead of producing a gtNewMustThrowException node, keep a second Log2 intrinsic and use the existing rationalization rewriting support to force it back to a call (this loses info that it definitively throws and is cold, which can be added is just a bit more complex)

---

Leaving this up to you

As for the overall change @EgorBo, I do think its worth it today and plan on taking it. We know Log2 is a building block API and had already had the rest of the foundational support here, it is very rare we get a change where the diffs (-321k bytes) and TP (-0.30% instructions retired) improvement are so definitively good (including both tests and some key production code methods, such as the primitive formatting/parsing helpers).

I also do understand the desire to handle these scenarios more generally via the inliner, but that's not going to happen today or even this release. I am more than happy to see us drop such JIT support in the future when the inliner is capable of handling it, the same as we've done with other intrinsic functionality (such as when we finally dropped the direct support for S.N.Vector2/3/4, Quaternion, Plane, etc).

[jkotas]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

[tannergooding]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

I'll see the diffs around the second alternative I gave then, carrying the throw path through as the rewritable intrinsic so it forces it back to the managed path in that case and preserves the exception.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[tannergooding]

Previously this was code was never being hit because we were checking against the non-precise var_type and so we always saw TYP_INT even for unsigned inputs. Now we correctly handle checking for unsigned inputs and allow importing signed ones as well.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the CoreCLR JIT importer for the NI_PRIMITIVE_Log2 primitive intrinsic to correctly distinguish signed vs. unsigned inputs using the precise type, enabling the intrinsic expansion for unsigned arguments and adding a conditional throw path for signed arguments.

Changes:

• Fixes signed/unsigned detection for Log2 by using JitType2PreciseVarType(baseJitType) rather than the non-precise baseType.
• Implements the Log2 expansion via LeadingZeroCount(value | 1) to satisfy the 0 -> 0 contract.
• Adds a conditional throw for negative signed inputs using a qmark-based fallback path.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[EgorBo]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK) and move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

The diffs here are significant. We see -321k bytes of codegen on Linux Arm64

Literally 99% of diffs are in libraries_tests.run. and all example diffs imply that

[Intrinsic]publicstaticuintLog2(uintvalue)=>(uint)BitOperations.Log2(value);

is not inlined. I suspect it might be either PGO-driven or it needs an AggressiveInlining.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

or just slap AggressiveInlining everywhere

cc @dotnet/jit-contrib for opinions

[tannergooding]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK)

I am doubtful that QMARK will ever fully go away as they have a significant benefit in that they allow introducing block like functionality (namely a compare + branch to throw an exception) into the code. If anything, it will just be replaced with a helper that does the creation of the if/else blocks at the point you're currently creating the QMARK node instead. They exist because it simplifies a bit of handling in the early phases and even allows some constant folding without forcing the block to actually be produced.

move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

Most compilers do this for the fundamental math APIs like this, we're not special and even have stricter timing requirements which means there is more reason for us to handle such APIs intrinsically as it significantly reduces the amount of work the JIT has to do. The inliner is always going to have limitations and there's no reason to contribute to its pessimizations for these foundational APIs everything else is built on.

Literally 99% of diffs are in libraries_tests.run.

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others. That's why I explicitly called out the hits we also have in other areas. But that's also representative of this code being "hot" and common to code that most apps and binaries end up using, even if indirectly.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

I don't think this is a fix and it just pushes things down the road more.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000:ldarg.0IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)IL_0006: ret

But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't. We skip all those checks, all the eating of the budget, and all the expensive handling by treating these key APIs as intrinsic. It completely bypasses the other expensive transforms and checks which ultimately simplifies what the JIT has to do, by adding a few lines to the importer to handle the known special scenarios.

[EgorBo]

I am doubtful that QMARK will ever fully go away as they have a significant benefit

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

The inliner is always going to have limitations

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users? I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about. Are you going to continue pushing various small methods as JIT intrinsics?

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

I do think we need to stop using it as an excuse. I agree on importing things as special opcodes so then JIT can emit those opcodes as part of other transformations and rely on proper expansion - that made sense to me, but it's no the case here as we just mimic inliner's work, not more than that.
Another downside of all of these intrinsics is that we continue adding binary size to jit while the original C# code can be trimmed.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000: ldarg.0
IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)
IL_0006: ret
But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't

I think we need to study why we give up, it might be something fundamental like abstract generic resolution in importer.
Or you just copied a diff from Tier0 that is not inlined. What is the Tier1 method we should look at?

[tannergooding]

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

My point here was rather that we have a fundamental need to introduce IR that represents x = cond ? throw : y and right now that is handled via QMARK. Even if we remove QMARK, it will just have to be replaced by something else that puts in the relevant blocks directly instead.

So even if they aren't the best IR today, the code is logically correct and will maintain roughly the current shape even when QMARKs disappear.

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users?

Because intrinsifying everything is both impossible and a negative. Most methods are not foundational in that sense and it would effectively cause "too much inlining", regress throughput, regress codegen size, etc.

Log2 is such a foundational helper, it and many of the APIs on the primitive types are the building blocks for all the other algorithms. It is an API that most compilers explicitly recognize and handle as intrinsic in some fashion, accordingly.

I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about.

I agree, but we also know this is much more complex work and that it will always have limits. So for foundational cases that are common to other compilers and where we can avoid some of the redundant work, it makes sense.

Are you going to continue pushing various small methods as JIT intrinsics?

The short answer is not really, fixing the existing Log2 handling really rounds out the set of them.

I'm not and have never been looking to intrinsify the world, only the key foundational math APIs like this one, i.e. the building blocks for the rest of .NET. Most of these were already handled and Log2 was one where we notably had handling but it was never firing because we were only checking TYP_INT and not TYP_UINT.

Of the foundational math APIs that aren't intrinsified, we only have integral Abs, Log10, Max, and Min. However, these likely aren't ever going to get handling because they aren't common to other compilers, don't have trivial hardware acceleration available, or do not have the size/ir complexity that other intrinsics have.

At best we might consider having Max/Min directly import as GT_CONDITIONAL to save on inlining and converting to those anyways, but then we really need the JIT to have better GT_CONDITIONAL support in the first place and because there isn't the size/ir complexity that other APIs have and we also want DPGO to work, I find it much less likely we do that.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

Does the FullOpts metric include T0? If it does we should probably split that out so we can actually differentiate MinOpts vs T0 vs T1 vs FullOpts, I had assumed it was just T1+FullOpts

I had downloaded the full diffs and saw most of the impactful changes in code that was actually proper fullopts or T1, i.e. the asmdiff says ; FullOpts code

One of the more robust cases is:

- ; 93 inlinees with PGO data; 314 single block inlinees; 54 inlinees without PGO data
+ ; 41 inlinees with PGO data; 85 single block inlinees; 11 inlinees without PGO data

going from 611 locals with a frame size of 632 down to 243 locals with a frame size of 104 and from 10112 bytes of codegen down to 1847 bytes of codegen

But for non tests it improves the codegen around string formatting for all integer primitives (via CountDigits and CountHexDigits), array sorting and the various Sorted* collections, some BigInteger handling particularly around ModPow, etc

This is also why there are so many triggers in tests, because Log2 is used in APIs that most apps, even trivial ones, end up using, so it triggers for a lot of code.

[EgorBo]

Leaving this up to you, I am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it. I understand that the debugging experience is worse in optimized code but I believe we've never changed the content of the exception before based on opts.

[tannergooding]

am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it

CC. @jkotas for input on this bit. The consideration is essentially whether it is okay for T1 (optimized) codegen for Log2 to differ in the message included as part of ArgumentOutOfRangeException from T0 (unoptimized/debug/t0) codegen?

I don't feel its worth complicating the JIT/VM to support preserving that message (ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_NeedNonNegNum) in the actual JIT throw helper support and it is okay for T1 code to differ here, particularly since its the only exception for this API.

The alternatives would be:

• Also drop the info from the exception in the managed fallback path
• Instead of producing a gtNewMustThrowException node, keep a second Log2 intrinsic and use the existing rationalization rewriting support to force it back to a call (this loses info that it definitively throws and is cold, which can be added is just a bit more complex)

---

Leaving this up to you

As for the overall change @EgorBo, I do think its worth it today and plan on taking it. We know Log2 is a building block API and had already had the rest of the foundational support here, it is very rare we get a change where the diffs (-321k bytes) and TP (-0.30% instructions retired) improvement are so definitively good (including both tests and some key production code methods, such as the primitive formatting/parsing helpers).

I also do understand the desire to handle these scenarios more generally via the inliner, but that's not going to happen today or even this release. I am more than happy to see us drop such JIT support in the future when the inliner is capable of handling it, the same as we've done with other intrinsic functionality (such as when we finally dropped the direct support for S.N.Vector2/3/4, Quaternion, Plane, etc).

[jkotas]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

[tannergooding]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

I'll see the diffs around the second alternative I gave then, carrying the throw path through as the rewritable intrinsic so it forces it back to the managed path in that case and preserves the exception.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[tannergooding]

Previously this was code was never being hit because we were checking against the non-precise var_type and so we always saw TYP_INT even for unsigned inputs. Now we correctly handle checking for unsigned inputs and allow importing signed ones as well.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the CoreCLR JIT importer for the NI_PRIMITIVE_Log2 primitive intrinsic to correctly distinguish signed vs. unsigned inputs using the precise type, enabling the intrinsic expansion for unsigned arguments and adding a conditional throw path for signed arguments.

Changes:

• Fixes signed/unsigned detection for Log2 by using JitType2PreciseVarType(baseJitType) rather than the non-precise baseType.
• Implements the Log2 expansion via LeadingZeroCount(value | 1) to satisfy the 0 -> 0 contract.
• Adds a conditional throw for negative signed inputs using a qmark-based fallback path.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[EgorBo]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK) and move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

The diffs here are significant. We see -321k bytes of codegen on Linux Arm64

Literally 99% of diffs are in libraries_tests.run. and all example diffs imply that

[Intrinsic]publicstaticuintLog2(uintvalue)=>(uint)BitOperations.Log2(value);

is not inlined. I suspect it might be either PGO-driven or it needs an AggressiveInlining.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

or just slap AggressiveInlining everywhere

cc @dotnet/jit-contrib for opinions

[tannergooding]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK)

I am doubtful that QMARK will ever fully go away as they have a significant benefit in that they allow introducing block like functionality (namely a compare + branch to throw an exception) into the code. If anything, it will just be replaced with a helper that does the creation of the if/else blocks at the point you're currently creating the QMARK node instead. They exist because it simplifies a bit of handling in the early phases and even allows some constant folding without forcing the block to actually be produced.

move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

Most compilers do this for the fundamental math APIs like this, we're not special and even have stricter timing requirements which means there is more reason for us to handle such APIs intrinsically as it significantly reduces the amount of work the JIT has to do. The inliner is always going to have limitations and there's no reason to contribute to its pessimizations for these foundational APIs everything else is built on.

Literally 99% of diffs are in libraries_tests.run.

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others. That's why I explicitly called out the hits we also have in other areas. But that's also representative of this code being "hot" and common to code that most apps and binaries end up using, even if indirectly.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

I don't think this is a fix and it just pushes things down the road more.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000:ldarg.0IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)IL_0006: ret

But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't. We skip all those checks, all the eating of the budget, and all the expensive handling by treating these key APIs as intrinsic. It completely bypasses the other expensive transforms and checks which ultimately simplifies what the JIT has to do, by adding a few lines to the importer to handle the known special scenarios.

[EgorBo]

I am doubtful that QMARK will ever fully go away as they have a significant benefit

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

The inliner is always going to have limitations

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users? I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about. Are you going to continue pushing various small methods as JIT intrinsics?

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

I do think we need to stop using it as an excuse. I agree on importing things as special opcodes so then JIT can emit those opcodes as part of other transformations and rely on proper expansion - that made sense to me, but it's no the case here as we just mimic inliner's work, not more than that.
Another downside of all of these intrinsics is that we continue adding binary size to jit while the original C# code can be trimmed.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000: ldarg.0
IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)
IL_0006: ret
But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't

I think we need to study why we give up, it might be something fundamental like abstract generic resolution in importer.
Or you just copied a diff from Tier0 that is not inlined. What is the Tier1 method we should look at?

[tannergooding]

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

My point here was rather that we have a fundamental need to introduce IR that represents x = cond ? throw : y and right now that is handled via QMARK. Even if we remove QMARK, it will just have to be replaced by something else that puts in the relevant blocks directly instead.

So even if they aren't the best IR today, the code is logically correct and will maintain roughly the current shape even when QMARKs disappear.

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users?

Because intrinsifying everything is both impossible and a negative. Most methods are not foundational in that sense and it would effectively cause "too much inlining", regress throughput, regress codegen size, etc.

Log2 is such a foundational helper, it and many of the APIs on the primitive types are the building blocks for all the other algorithms. It is an API that most compilers explicitly recognize and handle as intrinsic in some fashion, accordingly.

I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about.

I agree, but we also know this is much more complex work and that it will always have limits. So for foundational cases that are common to other compilers and where we can avoid some of the redundant work, it makes sense.

Are you going to continue pushing various small methods as JIT intrinsics?

The short answer is not really, fixing the existing Log2 handling really rounds out the set of them.

I'm not and have never been looking to intrinsify the world, only the key foundational math APIs like this one, i.e. the building blocks for the rest of .NET. Most of these were already handled and Log2 was one where we notably had handling but it was never firing because we were only checking TYP_INT and not TYP_UINT.

Of the foundational math APIs that aren't intrinsified, we only have integral Abs, Log10, Max, and Min. However, these likely aren't ever going to get handling because they aren't common to other compilers, don't have trivial hardware acceleration available, or do not have the size/ir complexity that other intrinsics have.

At best we might consider having Max/Min directly import as GT_CONDITIONAL to save on inlining and converting to those anyways, but then we really need the JIT to have better GT_CONDITIONAL support in the first place and because there isn't the size/ir complexity that other APIs have and we also want DPGO to work, I find it much less likely we do that.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

Does the FullOpts metric include T0? If it does we should probably split that out so we can actually differentiate MinOpts vs T0 vs T1 vs FullOpts, I had assumed it was just T1+FullOpts

I had downloaded the full diffs and saw most of the impactful changes in code that was actually proper fullopts or T1, i.e. the asmdiff says ; FullOpts code

One of the more robust cases is:

- ; 93 inlinees with PGO data; 314 single block inlinees; 54 inlinees without PGO data
+ ; 41 inlinees with PGO data; 85 single block inlinees; 11 inlinees without PGO data

going from 611 locals with a frame size of 632 down to 243 locals with a frame size of 104 and from 10112 bytes of codegen down to 1847 bytes of codegen

But for non tests it improves the codegen around string formatting for all integer primitives (via CountDigits and CountHexDigits), array sorting and the various Sorted* collections, some BigInteger handling particularly around ModPow, etc

This is also why there are so many triggers in tests, because Log2 is used in APIs that most apps, even trivial ones, end up using, so it triggers for a lot of code.

[EgorBo]

Leaving this up to you, I am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it. I understand that the debugging experience is worse in optimized code but I believe we've never changed the content of the exception before based on opts.

[tannergooding]

am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it

CC. @jkotas for input on this bit. The consideration is essentially whether it is okay for T1 (optimized) codegen for Log2 to differ in the message included as part of ArgumentOutOfRangeException from T0 (unoptimized/debug/t0) codegen?

I don't feel its worth complicating the JIT/VM to support preserving that message (ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_NeedNonNegNum) in the actual JIT throw helper support and it is okay for T1 code to differ here, particularly since its the only exception for this API.

The alternatives would be:

• Also drop the info from the exception in the managed fallback path
• Instead of producing a gtNewMustThrowException node, keep a second Log2 intrinsic and use the existing rationalization rewriting support to force it back to a call (this loses info that it definitively throws and is cold, which can be added is just a bit more complex)

---

Leaving this up to you

As for the overall change @EgorBo, I do think its worth it today and plan on taking it. We know Log2 is a building block API and had already had the rest of the foundational support here, it is very rare we get a change where the diffs (-321k bytes) and TP (-0.30% instructions retired) improvement are so definitively good (including both tests and some key production code methods, such as the primitive formatting/parsing helpers).

I also do understand the desire to handle these scenarios more generally via the inliner, but that's not going to happen today or even this release. I am more than happy to see us drop such JIT support in the future when the inliner is capable of handling it, the same as we've done with other intrinsic functionality (such as when we finally dropped the direct support for S.N.Vector2/3/4, Quaternion, Plane, etc).

[jkotas]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

[tannergooding]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

I'll see the diffs around the second alternative I gave then, carrying the throw path through as the rewritable intrinsic so it forces it back to the managed path in that case and preserves the exception.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[tannergooding]

Previously this was code was never being hit because we were checking against the non-precise var_type and so we always saw TYP_INT even for unsigned inputs. Now we correctly handle checking for unsigned inputs and allow importing signed ones as well.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the CoreCLR JIT importer for the NI_PRIMITIVE_Log2 primitive intrinsic to correctly distinguish signed vs. unsigned inputs using the precise type, enabling the intrinsic expansion for unsigned arguments and adding a conditional throw path for signed arguments.

Changes:

• Fixes signed/unsigned detection for Log2 by using JitType2PreciseVarType(baseJitType) rather than the non-precise baseType.
• Implements the Log2 expansion via LeadingZeroCount(value | 1) to satisfy the 0 -> 0 contract.
• Adds a conditional throw for negative signed inputs using a qmark-based fallback path.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[EgorBo]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK) and move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

The diffs here are significant. We see -321k bytes of codegen on Linux Arm64

Literally 99% of diffs are in libraries_tests.run. and all example diffs imply that

[Intrinsic]publicstaticuintLog2(uintvalue)=>(uint)BitOperations.Log2(value);

is not inlined. I suspect it might be either PGO-driven or it needs an AggressiveInlining.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

or just slap AggressiveInlining everywhere

cc @dotnet/jit-contrib for opinions

[tannergooding]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK)

I am doubtful that QMARK will ever fully go away as they have a significant benefit in that they allow introducing block like functionality (namely a compare + branch to throw an exception) into the code. If anything, it will just be replaced with a helper that does the creation of the if/else blocks at the point you're currently creating the QMARK node instead. They exist because it simplifies a bit of handling in the early phases and even allows some constant folding without forcing the block to actually be produced.

move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

Most compilers do this for the fundamental math APIs like this, we're not special and even have stricter timing requirements which means there is more reason for us to handle such APIs intrinsically as it significantly reduces the amount of work the JIT has to do. The inliner is always going to have limitations and there's no reason to contribute to its pessimizations for these foundational APIs everything else is built on.

Literally 99% of diffs are in libraries_tests.run.

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others. That's why I explicitly called out the hits we also have in other areas. But that's also representative of this code being "hot" and common to code that most apps and binaries end up using, even if indirectly.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

I don't think this is a fix and it just pushes things down the road more.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000:ldarg.0IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)IL_0006: ret

But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't. We skip all those checks, all the eating of the budget, and all the expensive handling by treating these key APIs as intrinsic. It completely bypasses the other expensive transforms and checks which ultimately simplifies what the JIT has to do, by adding a few lines to the importer to handle the known special scenarios.

[EgorBo]

I am doubtful that QMARK will ever fully go away as they have a significant benefit

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

The inliner is always going to have limitations

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users? I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about. Are you going to continue pushing various small methods as JIT intrinsics?

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

I do think we need to stop using it as an excuse. I agree on importing things as special opcodes so then JIT can emit those opcodes as part of other transformations and rely on proper expansion - that made sense to me, but it's no the case here as we just mimic inliner's work, not more than that.
Another downside of all of these intrinsics is that we continue adding binary size to jit while the original C# code can be trimmed.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000: ldarg.0
IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)
IL_0006: ret
But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't

I think we need to study why we give up, it might be something fundamental like abstract generic resolution in importer.
Or you just copied a diff from Tier0 that is not inlined. What is the Tier1 method we should look at?

[tannergooding]

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

My point here was rather that we have a fundamental need to introduce IR that represents x = cond ? throw : y and right now that is handled via QMARK. Even if we remove QMARK, it will just have to be replaced by something else that puts in the relevant blocks directly instead.

So even if they aren't the best IR today, the code is logically correct and will maintain roughly the current shape even when QMARKs disappear.

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users?

Because intrinsifying everything is both impossible and a negative. Most methods are not foundational in that sense and it would effectively cause "too much inlining", regress throughput, regress codegen size, etc.

Log2 is such a foundational helper, it and many of the APIs on the primitive types are the building blocks for all the other algorithms. It is an API that most compilers explicitly recognize and handle as intrinsic in some fashion, accordingly.

I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about.

I agree, but we also know this is much more complex work and that it will always have limits. So for foundational cases that are common to other compilers and where we can avoid some of the redundant work, it makes sense.

Are you going to continue pushing various small methods as JIT intrinsics?

The short answer is not really, fixing the existing Log2 handling really rounds out the set of them.

I'm not and have never been looking to intrinsify the world, only the key foundational math APIs like this one, i.e. the building blocks for the rest of .NET. Most of these were already handled and Log2 was one where we notably had handling but it was never firing because we were only checking TYP_INT and not TYP_UINT.

Of the foundational math APIs that aren't intrinsified, we only have integral Abs, Log10, Max, and Min. However, these likely aren't ever going to get handling because they aren't common to other compilers, don't have trivial hardware acceleration available, or do not have the size/ir complexity that other intrinsics have.

At best we might consider having Max/Min directly import as GT_CONDITIONAL to save on inlining and converting to those anyways, but then we really need the JIT to have better GT_CONDITIONAL support in the first place and because there isn't the size/ir complexity that other APIs have and we also want DPGO to work, I find it much less likely we do that.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

Does the FullOpts metric include T0? If it does we should probably split that out so we can actually differentiate MinOpts vs T0 vs T1 vs FullOpts, I had assumed it was just T1+FullOpts

I had downloaded the full diffs and saw most of the impactful changes in code that was actually proper fullopts or T1, i.e. the asmdiff says ; FullOpts code

One of the more robust cases is:

- ; 93 inlinees with PGO data; 314 single block inlinees; 54 inlinees without PGO data
+ ; 41 inlinees with PGO data; 85 single block inlinees; 11 inlinees without PGO data

going from 611 locals with a frame size of 632 down to 243 locals with a frame size of 104 and from 10112 bytes of codegen down to 1847 bytes of codegen

But for non tests it improves the codegen around string formatting for all integer primitives (via CountDigits and CountHexDigits), array sorting and the various Sorted* collections, some BigInteger handling particularly around ModPow, etc

This is also why there are so many triggers in tests, because Log2 is used in APIs that most apps, even trivial ones, end up using, so it triggers for a lot of code.

[EgorBo]

Leaving this up to you, I am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it. I understand that the debugging experience is worse in optimized code but I believe we've never changed the content of the exception before based on opts.

[tannergooding]

am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it

CC. @jkotas for input on this bit. The consideration is essentially whether it is okay for T1 (optimized) codegen for Log2 to differ in the message included as part of ArgumentOutOfRangeException from T0 (unoptimized/debug/t0) codegen?

I don't feel its worth complicating the JIT/VM to support preserving that message (ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_NeedNonNegNum) in the actual JIT throw helper support and it is okay for T1 code to differ here, particularly since its the only exception for this API.

The alternatives would be:

• Also drop the info from the exception in the managed fallback path
• Instead of producing a gtNewMustThrowException node, keep a second Log2 intrinsic and use the existing rationalization rewriting support to force it back to a call (this loses info that it definitively throws and is cold, which can be added is just a bit more complex)

---

Leaving this up to you

As for the overall change @EgorBo, I do think its worth it today and plan on taking it. We know Log2 is a building block API and had already had the rest of the foundational support here, it is very rare we get a change where the diffs (-321k bytes) and TP (-0.30% instructions retired) improvement are so definitively good (including both tests and some key production code methods, such as the primitive formatting/parsing helpers).

I also do understand the desire to handle these scenarios more generally via the inliner, but that's not going to happen today or even this release. I am more than happy to see us drop such JIT support in the future when the inliner is capable of handling it, the same as we've done with other intrinsic functionality (such as when we finally dropped the direct support for S.N.Vector2/3/4, Quaternion, Plane, etc).

[jkotas]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

[tannergooding]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

I'll see the diffs around the second alternative I gave then, carrying the throw path through as the rewritable intrinsic so it forces it back to the managed path in that case and preserves the exception.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[tannergooding]

Previously this was code was never being hit because we were checking against the non-precise var_type and so we always saw TYP_INT even for unsigned inputs. Now we correctly handle checking for unsigned inputs and allow importing signed ones as well.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the CoreCLR JIT importer for the NI_PRIMITIVE_Log2 primitive intrinsic to correctly distinguish signed vs. unsigned inputs using the precise type, enabling the intrinsic expansion for unsigned arguments and adding a conditional throw path for signed arguments.

Changes:

• Fixes signed/unsigned detection for Log2 by using JitType2PreciseVarType(baseJitType) rather than the non-precise baseType.
• Implements the Log2 expansion via LeadingZeroCount(value | 1) to satisfy the 0 -> 0 contract.
• Adds a conditional throw for negative signed inputs using a qmark-based fallback path.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[EgorBo]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK) and move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

The diffs here are significant. We see -321k bytes of codegen on Linux Arm64

Literally 99% of diffs are in libraries_tests.run. and all example diffs imply that

[Intrinsic]publicstaticuintLog2(uintvalue)=>(uint)BitOperations.Log2(value);

is not inlined. I suspect it might be either PGO-driven or it needs an AggressiveInlining.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

or just slap AggressiveInlining everywhere

cc @dotnet/jit-contrib for opinions

[tannergooding]

I am not a fan of these intrinsifications (especially when it has to import yet another QMARK)

I am doubtful that QMARK will ever fully go away as they have a significant benefit in that they allow introducing block like functionality (namely a compare + branch to throw an exception) into the code. If anything, it will just be replaced with a helper that does the creation of the if/else blocks at the point you're currently creating the QMARK node instead. They exist because it simplifies a bit of handling in the early phases and even allows some constant folding without forcing the block to actually be produced.

move all possible math functions to JIT intrinsics while it should just naturally be handled in the inliner.

Most compilers do this for the fundamental math APIs like this, we're not special and even have stricter timing requirements which means there is more reason for us to handle such APIs intrinsically as it significantly reduces the amount of work the JIT has to do. The inliner is always going to have limitations and there's no reason to contribute to its pessimizations for these foundational APIs everything else is built on.

Literally 99% of diffs are in libraries_tests.run.

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others. That's why I explicitly called out the hits we also have in other areas. But that's also representative of this code being "hot" and common to code that most apps and binaries end up using, even if indirectly.

My opinion we should just either look why e.g. in such a small method we don't inline it without AggressiveInlining on it:

I don't think this is a fix and it just pushes things down the road more.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000:ldarg.0IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)IL_0006: ret

But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't. We skip all those checks, all the eating of the budget, and all the expensive handling by treating these key APIs as intrinsic. It completely bypasses the other expensive transforms and checks which ultimately simplifies what the JIT has to do, by adding a few lines to the importer to handle the known special scenarios.

[EgorBo]

I am doubtful that QMARK will ever fully go away as they have a significant benefit

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

The inliner is always going to have limitations

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users? I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about. Are you going to continue pushing various small methods as JIT intrinsics?

This is the case with most diffs, as libraries_tests is a significant amount of code compared to the others.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

The general problem here is already known as well and we've discussed it many times, which is the inliner has a budget and it means we still give up on trivially getters, setters, and other direct calls like this.

I do think we need to stop using it as an excuse. I agree on importing things as special opcodes so then JIT can emit those opcodes as part of other transformations and rely on proper expansion - that made sense to me, but it's no the case here as we just mimic inliner's work, not more than that.
Another downside of all of these intrinsics is that we continue adding binary size to jit while the original C# code can be trimmed.

AggressiveInlining should even do nothing here because we are below the skipBudgetChecksSize (currently 12):

L_0000: ldarg.0
IL_0001: call int32 [System.Runtime]System.Numerics.BitOperations::Log2(uint32)
IL_0006: ret
But it does give up anyways, because we have dozens of heuristics and other checks for something that ultimately looks expensive but really isn't

I think we need to study why we give up, it might be something fundamental like abstract generic resolution in importer.
Or you just copied a diff from Tier0 that is not inlined. What is the Tier1 method we should look at?

[tannergooding]

Many phases between importer and global morph just bail on QMARKs (e.g. escape analysis), also, it introduces a very unobvious execution order (esp. nested qmarks) in trees all phases have to keep in mind, so removing it eventually will be a nice simplification. I am not saying it's bad, just needs a justification. E.g. I almost removed QMARKs for early cast expansion, my next goal is to remove the entire importervectorization.cpp, move it to a late phase.

My point here was rather that we have a fundamental need to introduce IR that represents x = cond ? throw : y and right now that is handled via QMARK. Even if we remove QMARK, it will just have to be replaced by something else that puts in the relevant blocks directly instead.

So even if they aren't the best IR today, the code is logically correct and will maintain roughly the current shape even when QMARKs disappear.

Why don't we intrinsify everything then, where is the line? Is Log2 that important for .NET users?

Because intrinsifying everything is both impossible and a negative. Most methods are not foundational in that sense and it would effectively cause "too much inlining", regress throughput, regress codegen size, etc.

Log2 is such a foundational helper, it and many of the APIs on the primitive types are the building blocks for all the other algorithms. It is an API that most compilers explicitly recognize and handle as intrinsic in some fashion, accordingly.

I think we need to continue investing into improving inliner instead. Making it much more reliable for things we care about.

I agree, but we also know this is much more complex work and that it will always have limits. So for foundational cases that are common to other compilers and where we can avoid some of the redundant work, it makes sense.

Are you going to continue pushing various small methods as JIT intrinsics?

The short answer is not really, fixing the existing Log2 handling really rounds out the set of them.

I'm not and have never been looking to intrinsify the world, only the key foundational math APIs like this one, i.e. the building blocks for the rest of .NET. Most of these were already handled and Log2 was one where we notably had handling but it was never firing because we were only checking TYP_INT and not TYP_UINT.

Of the foundational math APIs that aren't intrinsified, we only have integral Abs, Log10, Max, and Min. However, these likely aren't ever going to get handling because they aren't common to other compilers, don't have trivial hardware acceleration available, or do not have the size/ir complexity that other intrinsics have.

At best we might consider having Max/Min directly import as GT_CONDITIONAL to save on inlining and converting to those anyways, but then we really need the JIT to have better GT_CONDITIONAL support in the first place and because there isn't the size/ir complexity that other APIs have and we also want DPGO to work, I find it much less likely we do that.

All I see is a lot of pretty trivial tests for Log2 there which are now e.g. folded into constants in Tier0 thanks to this change.

Does the FullOpts metric include T0? If it does we should probably split that out so we can actually differentiate MinOpts vs T0 vs T1 vs FullOpts, I had assumed it was just T1+FullOpts

I had downloaded the full diffs and saw most of the impactful changes in code that was actually proper fullopts or T1, i.e. the asmdiff says ; FullOpts code

One of the more robust cases is:

- ; 93 inlinees with PGO data; 314 single block inlinees; 54 inlinees without PGO data
+ ; 41 inlinees with PGO data; 85 single block inlinees; 11 inlinees without PGO data

going from 611 locals with a frame size of 632 down to 243 locals with a frame size of 104 and from 10112 bytes of codegen down to 1847 bytes of codegen

But for non tests it improves the codegen around string formatting for all integer primitives (via CountDigits and CountHexDigits), array sorting and the various Sorted* collections, some BigInteger handling particularly around ModPow, etc

This is also why there are so many triggers in tests, because Log2 is used in APIs that most apps, even trivial ones, end up using, so it triggers for a lot of code.

[EgorBo]

Leaving this up to you, I am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it. I understand that the debugging experience is worse in optimized code but I believe we've never changed the content of the exception before based on opts.

[tannergooding]

am a litte bit concerned about the changed behavior with the different Exception message between Tier0/Debug/Tier1 and if it's worth it

CC. @jkotas for input on this bit. The consideration is essentially whether it is okay for T1 (optimized) codegen for Log2 to differ in the message included as part of ArgumentOutOfRangeException from T0 (unoptimized/debug/t0) codegen?

I don't feel its worth complicating the JIT/VM to support preserving that message (ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_NeedNonNegNum) in the actual JIT throw helper support and it is okay for T1 code to differ here, particularly since its the only exception for this API.

The alternatives would be:

• Also drop the info from the exception in the managed fallback path
• Instead of producing a gtNewMustThrowException node, keep a second Log2 intrinsic and use the existing rationalization rewriting support to force it back to a call (this loses info that it definitively throws and is cold, which can be added is just a bit more complex)

---

Leaving this up to you

As for the overall change @EgorBo, I do think its worth it today and plan on taking it. We know Log2 is a building block API and had already had the rest of the foundational support here, it is very rare we get a change where the diffs (-321k bytes) and TP (-0.30% instructions retired) improvement are so definitively good (including both tests and some key production code methods, such as the primitive formatting/parsing helpers).

I also do understand the desire to handle these scenarios more generally via the inliner, but that's not going to happen today or even this release. I am more than happy to see us drop such JIT support in the future when the inliner is capable of handling it, the same as we've done with other intrinsic functionality (such as when we finally dropped the direct support for S.N.Vector2/3/4, Quaternion, Plane, etc).

[jkotas]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

[tannergooding]

I do not think this is a good reason to start deviating error messages between debug and release for methods that are expected to be fully deterministic.

I'll see the diffs around the second alternative I gave then, carrying the throw path through as the rewritable intrinsic so it forces it back to the managed path in that case and preserves the exception.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.