Revert "Increase number of assertions (GlobalAP) + VN cache (#124132)"#124928
Revert "Increase number of assertions (GlobalAP) + VN cache (#124132)"#124928AndyAyersMS merged 1 commit intodotnet:mainfrom
Conversation
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
There was a problem hiding this comment.
Pull request overview
This PR reverts commit 92741be which introduced VN (Value Number) caching and a more sophisticated assertion count heuristic for the JIT's global assertion propagation optimization. The revert is necessary because the original changes caused excessive memory allocation during jitting.
Changes:
- Restored the original simpler IL-size-based assertion count heuristic (using a lookup table based on IL code size)
- Removed the VN-based caching mechanism (
optAssertionVNsMap) and related helper method (optAssertionHasAssertionsForVN) - Reverted early-exit optimizations that relied on the VN cache
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/coreclr/jit/rangecheck.cpp | Reverted VN cache check back to simple NoVN check in MergeEdgeAssertions |
| src/coreclr/jit/compiler.h | Removed optAssertionVNsMap field and optAssertionHasAssertionsForVN method declaration |
| src/coreclr/jit/assertionprop.cpp | Restored original assertion count heuristic, removed VN caching logic in optAddAssertion, removed optAssertionHasAssertionsForVN implementation, and removed VN-based early-exit optimizations |
adamperlin
left a comment
There was a problem hiding this comment.
I don't have the context to say what exactly is causing the issue here, but I'm signing off to unblock as this fix was confirmed to resolve the memory usage issue.
|
/ba-g build analysis stuck |
|
do we need to revert #124306 as well? it was a follow-up to the PR reverted here |
|
/backport to release/11.0-preview2 |
|
Started backporting to |
…AP) + VN cache (#124132)" (#124955) Backport of #124928 to release/11.0-preview2 /cc @akoeplinger @AndyAyersMS ## Customer Impact - [ ] Customer reported - [x] Found internally This was causing excessive memory allocation during jitting (see dotnet/dotnet#4933). ## Regression - [X] Yes - [ ] No Caused by: 92741be ## Testing Manual testing. ## Risk Low. Reverts an earlier change. [High/Medium/Low. Justify the indication by mentioning how risks were measured and addressed.] **IMPORTANT**: If this backport is for a servicing release, please verify that: - For .NET 8 and .NET 9: The PR target branch is `release/X.0-staging`, not `release/X.0`. - For .NET 10+: The PR target branch is `release/X.0` (no `-staging` suffix). ## Package authoring no longer needed in .NET 9 **IMPORTANT**: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version. Keep in mind that we still need package authoring in .NET 8 and older versions. Co-authored-by: Andy Ayers <andya@microsoft.com>
…124132)'" Re-applies the changes from PR #124132 that were reverted in PR #124928 due to a bug causing excessive memory allocation during jitting. The bug has since been fixed. Changes: - Formula-based optMaxAssertionCount heuristic (basicBlocks + tracked locals) - VN cache (optAssertionHasAssertionsForVN) for fast O(1) lookup - optAssertionVNsMap field added to Compiler - optAddAssertion uses VN cache for duplicate detection/registration - Early return in optAssertionProp_LclVar when no assertions for VN - VN cache check in optAssertionVNIsNonNull - rangecheck.cpp uses optAssertionHasAssertionsForVN instead of NoVN check - Includes addOpVN pattern fix from PR #124306 Co-authored-by: EgorBo <523221+EgorBo@users.noreply.github.com>
…124132)'" (#125215) [Diffs](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1321789&view=ms.vss-build-web.run-extensions-tab) Re-applies [#124132](#124132) which was reverted in [#124928](#124928) due to excessive JIT memory allocation. That root cause has since been fixed. ## Description **`assertionprop.cpp` / `compiler.h` — VN existence cache** - Adds `optAssertionVNsMap` (`VNSet*`): lazily-initialized map tracking which VNs have at least one assertion - Adds `optAssertionHasAssertionsForVN(vn, addIfNotFound)`: O(1) lookup; when `addIfNotFound=true` registers the VN on first insertion - `optAddAssertion`: uses the cache to gate the full O(n) table scan for duplicates; also registers `op2` bound VN and the `VN + const` operand VN (fix from [#124306](#124306)) so `MergeEdgeAssertions` can find them - `optAssertionProp_LclVar`: early-outs via cache before iterating assertions; pre-computes `treeVN` once instead of re-deriving it in the loop - `optAssertionVNIsNonNull`: skips iteration when cache says no assertions exist for the VN **`assertionprop.cpp` — `optMaxAssertionCount` heuristic** - Replaces the IL-code-size step-function table with the empirically-validated formula: ``` max(64, min(256, (lvaTrackedCount + 3 * fgBBcount + 48) >> 2)) ``` Validated across 1.1M compiled methods: 94.6% stay at the 64 floor, 0.4% hit the 256 cap, worst-case underprediction of 127 for 481 methods (0.043%). **`rangecheck.cpp`** - `MergeEdgeAssertions`: replaces `normalLclVN == NoVN` guard with `!optAssertionHasAssertionsForVN(normalLclVN)` — handles the `NoVN` case internally and also skips the loop when no relevant assertions were ever registered. <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/dotnet/runtime/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: EgorBo <523221+EgorBo@users.noreply.github.com>
This reverts commit 92741be.
This was causing excessive memory allocation during jitting (see dotnet/dotnet#4933).