C++: Make IR generation robust against functions with many declaring types #15316
+14
∄1�71
Conversation
This file contains 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
…more than 10 types. If it has more than 10 types we generate an unknown type.
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.
When we merged #12125 we started seeing a few (templated) member functions with many 1000s of (templated) declaring types.
We use the type of the declaring function to infer the result type of a write side effect on the qualifier of a member function call. And when there are
Ndeclaring types for a member function call, the write side effect hasNresult types 😱. This causes massive slowdowns in the IR alias analysis.This PR changes the IR generation of these write side effect instructions so that we return an "unknown type" rather than a large number of types if we're ever in a situation where there are more than 10 declaring types.
I picked 10 rather arbitrarily as the project I was testing this on had cases where there were 6 declaring types even before we merged #12125.
I haven't been able to reproduce this in a test, but on a project that exhibited this performance problem I'm seeing a difference in the output of PrintIR: https://www.diffchecker.com/CQ6UH8IN/