C++: Use local flow instead of GVN in getAdditionalFlowIntoCallNodeTerm - #12532
Merged
MathiasVP merged 5 commits intoMar 15, 2023
Conversation
…n switch statements.
…s in the same stage as 'DataFlowImplCommon'.
jketema
reviewed
Mar 15, 2023
…al-flow-for-getAdditionalFlowIntoCallNodeTerm
jketema
reviewed
Mar 15, 2023
jketema
approved these changes
Mar 15, 2023
jketema
left a comment
Contributor
There was a problem hiding this comment.
LGTM. For clarity: we agreed that the slight loss in DCA results is acceptable at this point and something we can revisit later.
MathiasVP
merged commit Mar 15, 2023
dffde8f
into
github:mathiasvp/replace-ast-with-ir-use-usedataflow
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 fixes a performance issue we've observed on a project, where the function was too complex for
GVNto figure out that a parameter was used in a switch statement. This meant that the performance-mitigation measure we implemented in #12236 didn't kick in.Commit-by-commit recommended. All the meat is in the first commit, and the second commit just moved things around for caching purposes.
We're losing a bunch of DCA results, but OTOH we're fixing a performance regression on a high-valued project. I'll create an internal issue to discuss how to get back some of these results.