JIT: Compute `fgCalledCount` after synthesis by amanasifkhalid · Pull Request #112041 · dotnet/runtime

amanasifkhalid · 2025-01-31T17:11:20Z

Part of #107749. Follow-up to #111971 and #110693. For methods without profile data, ensure the default call count is available throughout compilation (this had no diffs for me locally). For methods with profile data, compute the call count after synthesis runs to ensure it is available early, and reasonably accurate.

I'm only seeing diffs in OSR methods locally, due to the logic in fgFixEntryFlowForOSR (which runs right after profile incorporation) no longer affecting fgCalledCount. This method guesses that the loop iterates about 100x the method call count, and scales the method entry block's weight down accordingly. This gives the impression later on that fgCalledCount is much lower than what we calculated using fgEntryBB.

The actual diffs seem to manifest largely in LSRA, which uses fgCalledCount to normalize block weights, though there are a few other phases that use BasicBlock::getBBWeight in lieu of the raw weight as well. I think we ought to consolidate our block weight strategy at some point, especially if we have newfound faith in fgCalledCount. For example, instead of this check in if conversion:

if (m_startBlock->getBBWeight(m_comp) > BB_UNITY_WEIGHT * 1.05)

Perhaps we could do:

if (m_startBlock->bbWeight > fgCalledCount * 1.05)

But that's for another PR.

dotnet-policy-service · 2025-01-31T17:12:06Z

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

jakobbotsch

Nice! I had way larger diffs. Not sure what I was doing wrong.

amanasifkhalid · 2025-02-01T18:49:07Z

Nice! I had way larger diffs. Not sure what I was doing wrong.

I think #110693 just had to account for the entry block being different from fgFirstBB for OSR cases.

cc @dotnet/jit-contrib. Diffs. Build Analysis caught the "no module named 'requests'" failure in Linux-arm64 CI, but it didn't flag it as a known error...

amanasifkhalid · 2025-02-01T18:49:35Z

/ba-g blocked by dotnet/dnceng#4892.

* main: System.Net.Http.WinHttpHandler.StartRequestAsync assertion failed (dotnet#109799) Keep test PDB in helix payload for native AOT (dotnet#111949) Build the RID-specific System.IO.Ports packages in the VMR (dotnet#112054) Always inline number conversions (dotnet#112061) Use Contains{Any} in Regex source generator (dotnet#112065) Update dependencies from https://github.com/dotnet/arcade build 20250130.5 (dotnet#112013) JIT: Transform single-reg args to FIELD_LIST in physical promotion (dotnet#111590) Ensure that math calls into the CRT are tracked as needing vzeroupper (dotnet#112011) Use double.ConvertToIntegerNative where safe to do in System.Random (dotnet#112046) JIT: Compute `fgCalledCount` after synthesis (dotnet#112041) Simplify boolean logic in `TimeZoneInfo` (dotnet#112062) JIT: Update type when return temp is freshly created (dotnet#111948) Remove unused build controls and simplify DotNetBuild.props (dotnet#111986) Fix case-insensitive JSON deserialization of enum member names (dotnet#112028) WasmAppBuilder: Remove double computation of a value (dotnet#112047) Disable LTCG for brotli and zlibng. (dotnet#111805) JIT: Improve x86 unsigned to floating cast codegen (dotnet#111595) simplify x86 special intrinsic imports (dotnet#111836) JIT: Try to retain entry weight during profile synthesis (dotnet#111971) Fix explicit offset of ByRefLike fields. (dotnet#111584)

amanasifkhalid · 2025-01-31T17:11:20Z

Part of #107749. Follow-up to #111971 and #110693. For methods without profile data, ensure the default call count is available throughout compilation (this had no diffs for me locally). For methods with profile data, compute the call count after synthesis runs to ensure it is available early, and reasonably accurate.

I'm only seeing diffs in OSR methods locally, due to the logic in fgFixEntryFlowForOSR (which runs right after profile incorporation) no longer affecting fgCalledCount. This method guesses that the loop iterates about 100x the method call count, and scales the method entry block's weight down accordingly. This gives the impression later on that fgCalledCount is much lower than what we calculated using fgEntryBB.

The actual diffs seem to manifest largely in LSRA, which uses fgCalledCount to normalize block weights, though there are a few other phases that use BasicBlock::getBBWeight in lieu of the raw weight as well. I think we ought to consolidate our block weight strategy at some point, especially if we have newfound faith in fgCalledCount. For example, instead of this check in if conversion:

if (m_startBlock->getBBWeight(m_comp) > BB_UNITY_WEIGHT * 1.05)

Perhaps we could do:

if (m_startBlock->bbWeight > fgCalledCount * 1.05)

But that's for another PR.

dotnet-policy-service · 2025-01-31T17:12:06Z

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

jakobbotsch

Nice! I had way larger diffs. Not sure what I was doing wrong.

amanasifkhalid · 2025-02-01T18:49:07Z

Nice! I had way larger diffs. Not sure what I was doing wrong.

I think #110693 just had to account for the entry block being different from fgFirstBB for OSR cases.

cc @dotnet/jit-contrib. Diffs. Build Analysis caught the "no module named 'requests'" failure in Linux-arm64 CI, but it didn't flag it as a known error...

amanasifkhalid · 2025-02-01T18:49:35Z

/ba-g blocked by dotnet/dnceng#4892.

* main: System.Net.Http.WinHttpHandler.StartRequestAsync assertion failed (dotnet#109799) Keep test PDB in helix payload for native AOT (dotnet#111949) Build the RID-specific System.IO.Ports packages in the VMR (dotnet#112054) Always inline number conversions (dotnet#112061) Use Contains{Any} in Regex source generator (dotnet#112065) Update dependencies from https://github.com/dotnet/arcade build 20250130.5 (dotnet#112013) JIT: Transform single-reg args to FIELD_LIST in physical promotion (dotnet#111590) Ensure that math calls into the CRT are tracked as needing vzeroupper (dotnet#112011) Use double.ConvertToIntegerNative where safe to do in System.Random (dotnet#112046) JIT: Compute `fgCalledCount` after synthesis (dotnet#112041) Simplify boolean logic in `TimeZoneInfo` (dotnet#112062) JIT: Update type when return temp is freshly created (dotnet#111948) Remove unused build controls and simplify DotNetBuild.props (dotnet#111986) Fix case-insensitive JSON deserialization of enum member names (dotnet#112028) WasmAppBuilder: Remove double computation of a value (dotnet#112047) Disable LTCG for brotli and zlibng. (dotnet#111805) JIT: Improve x86 unsigned to floating cast codegen (dotnet#111595) simplify x86 special intrinsic imports (dotnet#111836) JIT: Try to retain entry weight during profile synthesis (dotnet#111971) Fix explicit offset of ByRefLike fields. (dotnet#111584)

amanasifkhalid · 2025-01-31T17:11:20Z

Part of #107749. Follow-up to #111971 and #110693. For methods without profile data, ensure the default call count is available throughout compilation (this had no diffs for me locally). For methods with profile data, compute the call count after synthesis runs to ensure it is available early, and reasonably accurate.

I'm only seeing diffs in OSR methods locally, due to the logic in fgFixEntryFlowForOSR (which runs right after profile incorporation) no longer affecting fgCalledCount. This method guesses that the loop iterates about 100x the method call count, and scales the method entry block's weight down accordingly. This gives the impression later on that fgCalledCount is much lower than what we calculated using fgEntryBB.

The actual diffs seem to manifest largely in LSRA, which uses fgCalledCount to normalize block weights, though there are a few other phases that use BasicBlock::getBBWeight in lieu of the raw weight as well. I think we ought to consolidate our block weight strategy at some point, especially if we have newfound faith in fgCalledCount. For example, instead of this check in if conversion:

if (m_startBlock->getBBWeight(m_comp) > BB_UNITY_WEIGHT * 1.05)

Perhaps we could do:

if (m_startBlock->bbWeight > fgCalledCount * 1.05)

But that's for another PR.

dotnet-policy-service · 2025-01-31T17:12:06Z

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

jakobbotsch

Nice! I had way larger diffs. Not sure what I was doing wrong.

amanasifkhalid · 2025-02-01T18:49:07Z

Nice! I had way larger diffs. Not sure what I was doing wrong.

I think #110693 just had to account for the entry block being different from fgFirstBB for OSR cases.

cc @dotnet/jit-contrib. Diffs. Build Analysis caught the "no module named 'requests'" failure in Linux-arm64 CI, but it didn't flag it as a known error...

amanasifkhalid · 2025-02-01T18:49:35Z

/ba-g blocked by dotnet/dnceng#4892.

* main: System.Net.Http.WinHttpHandler.StartRequestAsync assertion failed (dotnet#109799) Keep test PDB in helix payload for native AOT (dotnet#111949) Build the RID-specific System.IO.Ports packages in the VMR (dotnet#112054) Always inline number conversions (dotnet#112061) Use Contains{Any} in Regex source generator (dotnet#112065) Update dependencies from https://github.com/dotnet/arcade build 20250130.5 (dotnet#112013) JIT: Transform single-reg args to FIELD_LIST in physical promotion (dotnet#111590) Ensure that math calls into the CRT are tracked as needing vzeroupper (dotnet#112011) Use double.ConvertToIntegerNative where safe to do in System.Random (dotnet#112046) JIT: Compute `fgCalledCount` after synthesis (dotnet#112041) Simplify boolean logic in `TimeZoneInfo` (dotnet#112062) JIT: Update type when return temp is freshly created (dotnet#111948) Remove unused build controls and simplify DotNetBuild.props (dotnet#111986) Fix case-insensitive JSON deserialization of enum member names (dotnet#112028) WasmAppBuilder: Remove double computation of a value (dotnet#112047) Disable LTCG for brotli and zlibng. (dotnet#111805) JIT: Improve x86 unsigned to floating cast codegen (dotnet#111595) simplify x86 special intrinsic imports (dotnet#111836) JIT: Try to retain entry weight during profile synthesis (dotnet#111971) Fix explicit offset of ByRefLike fields. (dotnet#111584)

amanasifkhalid · 2025-01-31T17:11:20Z

Part of #107749. Follow-up to #111971 and #110693. For methods without profile data, ensure the default call count is available throughout compilation (this had no diffs for me locally). For methods with profile data, compute the call count after synthesis runs to ensure it is available early, and reasonably accurate.

I'm only seeing diffs in OSR methods locally, due to the logic in fgFixEntryFlowForOSR (which runs right after profile incorporation) no longer affecting fgCalledCount. This method guesses that the loop iterates about 100x the method call count, and scales the method entry block's weight down accordingly. This gives the impression later on that fgCalledCount is much lower than what we calculated using fgEntryBB.

The actual diffs seem to manifest largely in LSRA, which uses fgCalledCount to normalize block weights, though there are a few other phases that use BasicBlock::getBBWeight in lieu of the raw weight as well. I think we ought to consolidate our block weight strategy at some point, especially if we have newfound faith in fgCalledCount. For example, instead of this check in if conversion:

if (m_startBlock->getBBWeight(m_comp) > BB_UNITY_WEIGHT * 1.05)

Perhaps we could do:

if (m_startBlock->bbWeight > fgCalledCount * 1.05)

But that's for another PR.

dotnet-policy-service · 2025-01-31T17:12:06Z

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

jakobbotsch

Nice! I had way larger diffs. Not sure what I was doing wrong.

amanasifkhalid · 2025-02-01T18:49:07Z

Nice! I had way larger diffs. Not sure what I was doing wrong.

I think #110693 just had to account for the entry block being different from fgFirstBB for OSR cases.

cc @dotnet/jit-contrib. Diffs. Build Analysis caught the "no module named 'requests'" failure in Linux-arm64 CI, but it didn't flag it as a known error...

amanasifkhalid · 2025-02-01T18:49:35Z

/ba-g blocked by dotnet/dnceng#4892.

* main: System.Net.Http.WinHttpHandler.StartRequestAsync assertion failed (dotnet#109799) Keep test PDB in helix payload for native AOT (dotnet#111949) Build the RID-specific System.IO.Ports packages in the VMR (dotnet#112054) Always inline number conversions (dotnet#112061) Use Contains{Any} in Regex source generator (dotnet#112065) Update dependencies from https://github.com/dotnet/arcade build 20250130.5 (dotnet#112013) JIT: Transform single-reg args to FIELD_LIST in physical promotion (dotnet#111590) Ensure that math calls into the CRT are tracked as needing vzeroupper (dotnet#112011) Use double.ConvertToIntegerNative where safe to do in System.Random (dotnet#112046) JIT: Compute `fgCalledCount` after synthesis (dotnet#112041) Simplify boolean logic in `TimeZoneInfo` (dotnet#112062) JIT: Update type when return temp is freshly created (dotnet#111948) Remove unused build controls and simplify DotNetBuild.props (dotnet#111986) Fix case-insensitive JSON deserialization of enum member names (dotnet#112028) WasmAppBuilder: Remove double computation of a value (dotnet#112047) Disable LTCG for brotli and zlibng. (dotnet#111805) JIT: Improve x86 unsigned to floating cast codegen (dotnet#111595) simplify x86 special intrinsic imports (dotnet#111836) JIT: Try to retain entry weight during profile synthesis (dotnet#111971) Fix explicit offset of ByRefLike fields. (dotnet#111584)

amanasifkhalid · 2025-01-31T17:11:20Z

Part of #107749. Follow-up to #111971 and #110693. For methods without profile data, ensure the default call count is available throughout compilation (this had no diffs for me locally). For methods with profile data, compute the call count after synthesis runs to ensure it is available early, and reasonably accurate.

I'm only seeing diffs in OSR methods locally, due to the logic in fgFixEntryFlowForOSR (which runs right after profile incorporation) no longer affecting fgCalledCount. This method guesses that the loop iterates about 100x the method call count, and scales the method entry block's weight down accordingly. This gives the impression later on that fgCalledCount is much lower than what we calculated using fgEntryBB.

The actual diffs seem to manifest largely in LSRA, which uses fgCalledCount to normalize block weights, though there are a few other phases that use BasicBlock::getBBWeight in lieu of the raw weight as well. I think we ought to consolidate our block weight strategy at some point, especially if we have newfound faith in fgCalledCount. For example, instead of this check in if conversion:

if (m_startBlock->getBBWeight(m_comp) > BB_UNITY_WEIGHT * 1.05)

Perhaps we could do:

if (m_startBlock->bbWeight > fgCalledCount * 1.05)

But that's for another PR.

dotnet-policy-service · 2025-01-31T17:12:06Z

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

jakobbotsch

Nice! I had way larger diffs. Not sure what I was doing wrong.

amanasifkhalid · 2025-02-01T18:49:07Z

Nice! I had way larger diffs. Not sure what I was doing wrong.

I think #110693 just had to account for the entry block being different from fgFirstBB for OSR cases.

cc @dotnet/jit-contrib. Diffs. Build Analysis caught the "no module named 'requests'" failure in Linux-arm64 CI, but it didn't flag it as a known error...

amanasifkhalid · 2025-02-01T18:49:35Z

/ba-g blocked by dotnet/dnceng#4892.

* main: System.Net.Http.WinHttpHandler.StartRequestAsync assertion failed (dotnet#109799) Keep test PDB in helix payload for native AOT (dotnet#111949) Build the RID-specific System.IO.Ports packages in the VMR (dotnet#112054) Always inline number conversions (dotnet#112061) Use Contains{Any} in Regex source generator (dotnet#112065) Update dependencies from https://github.com/dotnet/arcade build 20250130.5 (dotnet#112013) JIT: Transform single-reg args to FIELD_LIST in physical promotion (dotnet#111590) Ensure that math calls into the CRT are tracked as needing vzeroupper (dotnet#112011) Use double.ConvertToIntegerNative where safe to do in System.Random (dotnet#112046) JIT: Compute `fgCalledCount` after synthesis (dotnet#112041) Simplify boolean logic in `TimeZoneInfo` (dotnet#112062) JIT: Update type when return temp is freshly created (dotnet#111948) Remove unused build controls and simplify DotNetBuild.props (dotnet#111986) Fix case-insensitive JSON deserialization of enum member names (dotnet#112028) WasmAppBuilder: Remove double computation of a value (dotnet#112047) Disable LTCG for brotli and zlibng. (dotnet#111805) JIT: Improve x86 unsigned to floating cast codegen (dotnet#111595) simplify x86 special intrinsic imports (dotnet#111836) JIT: Try to retain entry weight during profile synthesis (dotnet#111971) Fix explicit offset of ByRefLike fields. (dotnet#111584)

amanasifkhalid · 2025-01-31T17:11:20Z

Part of #107749. Follow-up to #111971 and #110693. For methods without profile data, ensure the default call count is available throughout compilation (this had no diffs for me locally). For methods with profile data, compute the call count after synthesis runs to ensure it is available early, and reasonably accurate.

I'm only seeing diffs in OSR methods locally, due to the logic in fgFixEntryFlowForOSR (which runs right after profile incorporation) no longer affecting fgCalledCount. This method guesses that the loop iterates about 100x the method call count, and scales the method entry block's weight down accordingly. This gives the impression later on that fgCalledCount is much lower than what we calculated using fgEntryBB.

The actual diffs seem to manifest largely in LSRA, which uses fgCalledCount to normalize block weights, though there are a few other phases that use BasicBlock::getBBWeight in lieu of the raw weight as well. I think we ought to consolidate our block weight strategy at some point, especially if we have newfound faith in fgCalledCount. For example, instead of this check in if conversion:

if (m_startBlock->getBBWeight(m_comp) > BB_UNITY_WEIGHT * 1.05)

Perhaps we could do:

if (m_startBlock->bbWeight > fgCalledCount * 1.05)

But that's for another PR.

dotnet-policy-service · 2025-01-31T17:12:06Z

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

jakobbotsch

Nice! I had way larger diffs. Not sure what I was doing wrong.

amanasifkhalid · 2025-02-01T18:49:07Z

Nice! I had way larger diffs. Not sure what I was doing wrong.

I think #110693 just had to account for the entry block being different from fgFirstBB for OSR cases.

cc @dotnet/jit-contrib. Diffs. Build Analysis caught the "no module named 'requests'" failure in Linux-arm64 CI, but it didn't flag it as a known error...

amanasifkhalid · 2025-02-01T18:49:35Z

/ba-g blocked by dotnet/dnceng#4892.

* main: System.Net.Http.WinHttpHandler.StartRequestAsync assertion failed (dotnet#109799) Keep test PDB in helix payload for native AOT (dotnet#111949) Build the RID-specific System.IO.Ports packages in the VMR (dotnet#112054) Always inline number conversions (dotnet#112061) Use Contains{Any} in Regex source generator (dotnet#112065) Update dependencies from https://github.com/dotnet/arcade build 20250130.5 (dotnet#112013) JIT: Transform single-reg args to FIELD_LIST in physical promotion (dotnet#111590) Ensure that math calls into the CRT are tracked as needing vzeroupper (dotnet#112011) Use double.ConvertToIntegerNative where safe to do in System.Random (dotnet#112046) JIT: Compute `fgCalledCount` after synthesis (dotnet#112041) Simplify boolean logic in `TimeZoneInfo` (dotnet#112062) JIT: Update type when return temp is freshly created (dotnet#111948) Remove unused build controls and simplify DotNetBuild.props (dotnet#111986) Fix case-insensitive JSON deserialization of enum member names (dotnet#112028) WasmAppBuilder: Remove double computation of a value (dotnet#112047) Disable LTCG for brotli and zlibng. (dotnet#111805) JIT: Improve x86 unsigned to floating cast codegen (dotnet#111595) simplify x86 special intrinsic imports (dotnet#111836) JIT: Try to retain entry weight during profile synthesis (dotnet#111971) Fix explicit offset of ByRefLike fields. (dotnet#111584)

amanasifkhalid · 2025-01-31T17:11:20Z

Part of #107749. Follow-up to #111971 and #110693. For methods without profile data, ensure the default call count is available throughout compilation (this had no diffs for me locally). For methods with profile data, compute the call count after synthesis runs to ensure it is available early, and reasonably accurate.

I'm only seeing diffs in OSR methods locally, due to the logic in fgFixEntryFlowForOSR (which runs right after profile incorporation) no longer affecting fgCalledCount. This method guesses that the loop iterates about 100x the method call count, and scales the method entry block's weight down accordingly. This gives the impression later on that fgCalledCount is much lower than what we calculated using fgEntryBB.

The actual diffs seem to manifest largely in LSRA, which uses fgCalledCount to normalize block weights, though there are a few other phases that use BasicBlock::getBBWeight in lieu of the raw weight as well. I think we ought to consolidate our block weight strategy at some point, especially if we have newfound faith in fgCalledCount. For example, instead of this check in if conversion:

if (m_startBlock->getBBWeight(m_comp) > BB_UNITY_WEIGHT * 1.05)

Perhaps we could do:

if (m_startBlock->bbWeight > fgCalledCount * 1.05)

But that's for another PR.

dotnet-policy-service · 2025-01-31T17:12:06Z

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

jakobbotsch

Nice! I had way larger diffs. Not sure what I was doing wrong.

amanasifkhalid · 2025-02-01T18:49:07Z

Nice! I had way larger diffs. Not sure what I was doing wrong.

I think #110693 just had to account for the entry block being different from fgFirstBB for OSR cases.

cc @dotnet/jit-contrib. Diffs. Build Analysis caught the "no module named 'requests'" failure in Linux-arm64 CI, but it didn't flag it as a known error...

amanasifkhalid · 2025-02-01T18:49:35Z

/ba-g blocked by dotnet/dnceng#4892.

* main: System.Net.Http.WinHttpHandler.StartRequestAsync assertion failed (dotnet#109799) Keep test PDB in helix payload for native AOT (dotnet#111949) Build the RID-specific System.IO.Ports packages in the VMR (dotnet#112054) Always inline number conversions (dotnet#112061) Use Contains{Any} in Regex source generator (dotnet#112065) Update dependencies from https://github.com/dotnet/arcade build 20250130.5 (dotnet#112013) JIT: Transform single-reg args to FIELD_LIST in physical promotion (dotnet#111590) Ensure that math calls into the CRT are tracked as needing vzeroupper (dotnet#112011) Use double.ConvertToIntegerNative where safe to do in System.Random (dotnet#112046) JIT: Compute `fgCalledCount` after synthesis (dotnet#112041) Simplify boolean logic in `TimeZoneInfo` (dotnet#112062) JIT: Update type when return temp is freshly created (dotnet#111948) Remove unused build controls and simplify DotNetBuild.props (dotnet#111986) Fix case-insensitive JSON deserialization of enum member names (dotnet#112028) WasmAppBuilder: Remove double computation of a value (dotnet#112047) Disable LTCG for brotli and zlibng. (dotnet#111805) JIT: Improve x86 unsigned to floating cast codegen (dotnet#111595) simplify x86 special intrinsic imports (dotnet#111836) JIT: Try to retain entry weight during profile synthesis (dotnet#111971) Fix explicit offset of ByRefLike fields. (dotnet#111584)

amanasifkhalid · 2025-01-31T17:11:20Z

Part of #107749. Follow-up to #111971 and #110693. For methods without profile data, ensure the default call count is available throughout compilation (this had no diffs for me locally). For methods with profile data, compute the call count after synthesis runs to ensure it is available early, and reasonably accurate.

I'm only seeing diffs in OSR methods locally, due to the logic in fgFixEntryFlowForOSR (which runs right after profile incorporation) no longer affecting fgCalledCount. This method guesses that the loop iterates about 100x the method call count, and scales the method entry block's weight down accordingly. This gives the impression later on that fgCalledCount is much lower than what we calculated using fgEntryBB.

The actual diffs seem to manifest largely in LSRA, which uses fgCalledCount to normalize block weights, though there are a few other phases that use BasicBlock::getBBWeight in lieu of the raw weight as well. I think we ought to consolidate our block weight strategy at some point, especially if we have newfound faith in fgCalledCount. For example, instead of this check in if conversion:

if (m_startBlock->getBBWeight(m_comp) > BB_UNITY_WEIGHT * 1.05)

Perhaps we could do:

if (m_startBlock->bbWeight > fgCalledCount * 1.05)

But that's for another PR.

dotnet-policy-service · 2025-01-31T17:12:06Z

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

jakobbotsch

Nice! I had way larger diffs. Not sure what I was doing wrong.

amanasifkhalid · 2025-02-01T18:49:07Z

Nice! I had way larger diffs. Not sure what I was doing wrong.

I think #110693 just had to account for the entry block being different from fgFirstBB for OSR cases.

cc @dotnet/jit-contrib. Diffs. Build Analysis caught the "no module named 'requests'" failure in Linux-arm64 CI, but it didn't flag it as a known error...

amanasifkhalid · 2025-02-01T18:49:35Z

/ba-g blocked by dotnet/dnceng#4892.

* main: System.Net.Http.WinHttpHandler.StartRequestAsync assertion failed (dotnet#109799) Keep test PDB in helix payload for native AOT (dotnet#111949) Build the RID-specific System.IO.Ports packages in the VMR (dotnet#112054) Always inline number conversions (dotnet#112061) Use Contains{Any} in Regex source generator (dotnet#112065) Update dependencies from https://github.com/dotnet/arcade build 20250130.5 (dotnet#112013) JIT: Transform single-reg args to FIELD_LIST in physical promotion (dotnet#111590) Ensure that math calls into the CRT are tracked as needing vzeroupper (dotnet#112011) Use double.ConvertToIntegerNative where safe to do in System.Random (dotnet#112046) JIT: Compute `fgCalledCount` after synthesis (dotnet#112041) Simplify boolean logic in `TimeZoneInfo` (dotnet#112062) JIT: Update type when return temp is freshly created (dotnet#111948) Remove unused build controls and simplify DotNetBuild.props (dotnet#111986) Fix case-insensitive JSON deserialization of enum member names (dotnet#112028) WasmAppBuilder: Remove double computation of a value (dotnet#112047) Disable LTCG for brotli and zlibng. (dotnet#111805) JIT: Improve x86 unsigned to floating cast codegen (dotnet#111595) simplify x86 special intrinsic imports (dotnet#111836) JIT: Try to retain entry weight during profile synthesis (dotnet#111971) Fix explicit offset of ByRefLike fields. (dotnet#111584)

Compute fgCalledCount after synthesis
2df3676

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 31, 2025

dotnet-policy-serviceBot assigned amanasifkhalid Jan 31, 2025

EgorBo mentioned this pull request Feb 2, 2025
[Linux-arm64] ModuleNotFoundError: No module named 'requests' dotnet/dnceng#4892
Closed
6 tasks

jakobbotsch approved these changes Jan 31, 2025
View reviewed changes

amanasifkhalid merged commit 9c456f6 into dotnet:mainFeb 1, 2025

amanasifkhalid deleted the move-fgCalledCount branch February 1, 2025 18:50

AndyAyersMS mentioned this pull request Feb 4, 2025
[Perf] Windows/x64: 19 Improvements on 2/1/2025 7:06:23 PM +00:00 dotnet/perf-autofiling-issues#49493
Closed

LoopedBard3 mentioned this pull request Feb 4, 2025
[Perf] Linux/x64: 25 Regressions on 2/1/2025 7:06:23 PM +00:00 #112133
Closed

This was referenced Feb 4, 2025
[Perf] Linux/x64: 11 Improvements on 2/1/2025 7:06:23 PM +00:00 dotnet/perf-autofiling-issues#49415
Closed
[Perf] Windows/x64: 5 Improvements on 2/1/2025 7:06:23 PM +00:00 dotnet/perf-autofiling-issues#49485
Closed

amanasifkhalid mentioned this pull request Mar 4, 2025
Benchmark Regressions from Profile Maintenance and Block Layout Changes #113108
Closed

github-actionsBot locked and limited conversation to collaborators Mar 6, 2025