[compiler] Separate InferFunctionEffects pass from InferReferenceEffects #30975
+181
−72
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
Test Plan:
This diff finally separates InferFunctionEffects into its own separate pass from InferReferenceEffects. It relies on the abstractValues populated in IRE as well as the alias sets that IRE returns.
The meat of the InferFunctionEffects algorithm is still the same, but rather than querying the "live" InferenceState from IRE for abstract values and alias information, we query the values defined on places and the alias set returned by IRE.
One extra bit of work that we now need to perform is creating a map from IdentifierIds to AbstractValues, which we do by traversing the HIRFunction and examining all places. We also need to track the computed effects of nested functions, and that's where the disjoint set of aliases comes in -- when performing the main algorithm, we might see a set of instructions like
```
$0 = Function (effect=ContextMutation) { ... }
$1 = LoadLocal $0
$2 = Call $1 ()
```
When examining the `Call` instruction, we need to know that $1 has the function effect [ContextMutation]. Since $0 and $1 were inferred to be aliased by IRE, we don't need to do any other propagation from $0 to $1 if we track the nested effects based on the root of the alias set { $0, $1 } rather than the specific identifier $1 present in the Call instruction.
[ghstack-poisoned]
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This was referenced Sep 16, 2024
…ferenceEffects"
Test Plan:
This diff finally separates InferFunctionEffects into its own separate pass from InferReferenceEffects. It relies on the abstractValues populated in IRE as well as the alias sets that IRE returns.
The meat of the InferFunctionEffects algorithm is still the same, but rather than querying the "live" InferenceState from IRE for abstract values and alias information, we query the values defined on places and the alias set returned by IRE.
One extra bit of work that we now need to perform is creating a map from IdentifierIds to AbstractValues, which we do by traversing the HIRFunction and examining all places. We also need to track the computed effects of nested functions, and that's where the disjoint set of aliases comes in -- when performing the main algorithm, we might see a set of instructions like
```
$0 = Function (effect=ContextMutation) { ... }
$1 = LoadLocal $0
$2 = Call $1 ()
```
When examining the `Call` instruction, we need to know that $1 has the function effect [ContextMutation]. Since $0 and $1 were inferred to be aliased by IRE, we don't need to do any other propagation from $0 to $1 if we track the nested effects based on the root of the alias set { $0, $1 } rather than the specific identifier $1 present in the Call instruction.
[ghstack-poisoned]
|
(currently testing this internally -- will move out of draft mode if internal results look good) |
…ferenceEffects"
Test Plan:
This diff finally separates InferFunctionEffects into its own separate pass from InferReferenceEffects. It relies on the abstractValues populated in IRE as well as the alias sets that IRE returns.
The meat of the InferFunctionEffects algorithm is still the same, but rather than querying the "live" InferenceState from IRE for abstract values and alias information, we query the values defined on places and the alias set returned by IRE.
One extra bit of work that we now need to perform is creating a map from IdentifierIds to AbstractValues, which we do by traversing the HIRFunction and examining all places. We also need to track the computed effects of nested functions, and that's where the disjoint set of aliases comes in -- when performing the main algorithm, we might see a set of instructions like
```
$0 = Function (effect=ContextMutation) { ... }
$1 = LoadLocal $0
$2 = Call $1 ()
```
When examining the `Call` instruction, we need to know that $1 has the function effect [ContextMutation]. Since $0 and $1 were inferred to be aliased by IRE, we don't need to do any other propagation from $0 to $1 if we track the nested effects based on the root of the alias set { $0, $1 } rather than the specific identifier $1 present in the Call instruction.
[ghstack-poisoned]
…ferenceEffects"
Test Plan:
This diff finally separates InferFunctionEffects into its own separate pass from InferReferenceEffects. It relies on the abstractValues populated in IRE as well as the alias sets that IRE returns.
The meat of the InferFunctionEffects algorithm is still the same, but rather than querying the "live" InferenceState from IRE for abstract values and alias information, we query the values defined on places and the alias set returned by IRE.
One extra bit of work that we now need to perform is creating a map from IdentifierIds to AbstractValues, which we do by traversing the HIRFunction and examining all places. We also need to track the computed effects of nested functions, and that's where the disjoint set of aliases comes in -- when performing the main algorithm, we might see a set of instructions like
```
$0 = Function (effect=ContextMutation) { ... }
$1 = LoadLocal $0
$2 = Call $1 ()
```
When examining the `Call` instruction, we need to know that $1 has the function effect [ContextMutation]. Since $0 and $1 were inferred to be aliased by IRE, we don't need to do any other propagation from $0 to $1 if we track the nested effects based on the root of the alias set { $0, $1 } rather than the specific identifier $1 present in the Call instruction.
[ghstack-poisoned]
…ferenceEffects"
Test Plan:
This diff finally separates InferFunctionEffects into its own separate pass from InferReferenceEffects. It relies on the abstractValues populated in IRE as well as the alias sets that IRE returns.
The meat of the InferFunctionEffects algorithm is still the same, but rather than querying the "live" InferenceState from IRE for abstract values and alias information, we query the values defined on places and the alias set returned by IRE.
One extra bit of work that we now need to perform is creating a map from IdentifierIds to AbstractValues, which we do by traversing the HIRFunction and examining all places. We also need to track the computed effects of nested functions, and that's where the disjoint set of aliases comes in -- when performing the main algorithm, we might see a set of instructions like
```
$0 = Function (effect=ContextMutation) { ... }
$1 = LoadLocal $0
$2 = Call $1 ()
```
When examining the `Call` instruction, we need to know that $1 has the function effect [ContextMutation]. Since $0 and $1 were inferred to be aliased by IRE, we don't need to do any other propagation from $0 to $1 if we track the nested effects based on the root of the alias set { $0, $1 } rather than the specific identifier $1 present in the Call instruction.
[ghstack-poisoned]
|
P1592845685 for the internal sync. No changes to the function effect errors. |
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.
Stack from ghstack (oldest at bottom):
Test Plan:
This diff finally separates InferFunctionEffects into its own separate pass from InferReferenceEffects. It relies on the abstractValues populated in IRE as well as the alias sets that IRE returns.
The meat of the InferFunctionEffects algorithm is still the same, but rather than querying the "live" InferenceState from IRE for abstract values and alias information, we query the values defined on places and the alias set returned by IRE.
One extra bit of work that we now need to perform is creating a map from IdentifierIds to AbstractValues, which we do by traversing the HIRFunction and examining all places. We also need to track the computed effects of nested functions, and that's where the disjoint set of aliases comes in -- when performing the main algorithm, we might see a set of instructions like
When examining the
Callinstruction, we need to know that $1 has the function effect [ContextMutation]. Since $0 and $1 were inferred to be aliased by IRE, we don't need to do any other propagation from $0 to $1 if we track the nested effects based on the root of the alias set { $0, $1 } rather than the specific identifier $1 present in the Call instruction.