[NFC] DeadArgumentElimination: Compute callers once #8053
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tlively
approved these changes
Nov 17, 2025
| // param, we see the call is not reached). This is somewhat rare, and the cost | ||
| // of computing this map is significant, so we compute it once at the start | ||
| // and then use that possibly-over-approximating data. | ||
| std::vector<std::unordered_set<Name>> callers; |
Member
There was a problem hiding this comment.
Maybe we can make these even faster by making the inner set into another vector.
Member
Author
There was a problem hiding this comment.
Good idea, done. I can't seem to measure a speedup from it, but maybe it depends on CPU or workload, and the vectors should be better.
Co-authored-by: Thomas Lively <tlively123@gmail.com>
tlively
approved these changes
Nov 17, 2025
Co-authored-by: Thomas Lively <tlively123@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an over-approximation, as later iterations may have fewer calls - if we
remove a call. Such removal is rare, however, and the cost of computing this
map is actually very high. Computing it once up front, and using that over-
approximation, turns out to be much faster, even if in theory it can lead to a
little wasted work (more scanning; but no optimizations are missed, as we do
not use this mapping to decide what/how to optimize).
This makes the pass 30-40% faster on several large testcases I tried, from
Dart, Java, and C++. I did see two testcases that benefited only by 10-20%,
from GraalVM and Rust, but I saw none that did not benefit significantly.
This was the slowest pass in some of those 30-40% cases.
Helps #4165