Refactor irinterp refinement logic #50155
Merged
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 continues the refactoring begun by #49340 to have irinterp consume the IR_FLAG_REFINED flag. This essentially has the same effect as the extra_reprocess bitset that irinterp takes, so we can remove that. However, there is a related issue where we would like to inform irinterp that we have already refined the type of a particular statement (likely using information not available to the irinterp) and would like it to just propagate that if possible. So bring back that extra bitset with a new name and these new semantics to make that possible.
While I was working on this, I also noticed that the control hook I added in #48199 wasn't quite working as advertised. I don't currently need it, so rather than trying to work through an API without a concrete consumer, just nuke that hook for now. I do still think it'll be required at some point, but we can always add it back.