-
Notifications
You must be signed in to change notification settings - Fork 48.8k
[compiler][rewrite] Represent scope dependencies with value blocks #32099
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i did a quick skim through, this is just some early feedback
@@ -3414,7 +3413,7 @@ function lowerExpressionToTemporary( | |||
return lowerValueToTemporary(builder, value); | |||
} | |||
|
|||
function lowerValueToTemporary( | |||
export function lowerValueToTemporary( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not used outside this file, remove the export?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is used in propagateScopeDependencies
, which creates new instructions / temporaries for scope dependency blocks
@@ -902,6 +904,7 @@ export class Environment { | |||
this.#moduleTypes.set(REANIMATED_MODULE_NAME, reanimatedModuleType); | |||
} | |||
|
|||
this.parentFunction = parentFunction; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: splitting changes like this into a separate PR would make it easier to review and focus on the core dependency changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not processed the changes here deeply, but my first instinct is to wonder why this pass should have to change at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're now representing scope dependencies with value blocks + a list of Place
s, two things need to change:
- Promoting unnamed
Identifier
s referenced by scope dependencies now requires explicitly traversing the value blocks (seethis.visitBlock(scopeBlock.dependencyInstructions, ...)
- We now also need to perform some form of DCE -- after pruning passes, some instructions within
scopeBlock.dependencyInstructions
no longer correspond to real dependencies. Concretely, we need to figure out which baseIdentifier
s should be excluded for promotion.
Note that this isn't an issue for codegen asReactiveScopeBlock.dependencyInstructions
always contains non-named, non-null lvalues (which simply stores into aTemporaries: Map<Identifier, babel.t.Expression>
sidemap for later inlining
Small patch to pass aliased context values into `Object|ArrayExpression`s --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32093). * #32099 * #32104 * #32098 * #32097 * #32096 * #32095 * #32094 * __->__ #32093
See test fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32094). * #32099 * #32104 * #32098 * #32097 * #32096 * #32095 * __->__ #32094 * #32093
See test fixture --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32095). * #32099 * #32104 * #32098 * #32097 * #32096 * __->__ #32095 * #32094 * #32093
getOrCreateIdentifier( | ||
identifier: Identifier, | ||
reactive: boolean, | ||
): PropertyPathNode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that we now need to track reactivity, as we're creating new instructions to represent dependencies
Synced offline with @josephsavona, I'm going to hold off on landing this until after:
|
…ns (#32096) LoweredFunction dependencies were exclusively used for dependency extraction (in `propagateScopeDeps`). Now that we have a `propagateScopeDepsHIR` that recursively traverses into nested functions, we can delete `dependencies` and their associated synthetic `LoadLocal`/`PropertyLoad` instructions. [Internal snapshot diff](https://www.internalfb.com/phabricator/paste/view/P1716950202) for this change shows ~.2% of files changed. I [read through ~60 of the changed files](https://www.internalfb.com/phabricator/paste/view/P1733074307) - most changes are due to better outlining (due to better DCE) - a few changes in memo inference are due to changed ordering ``` // source arr.map(() => contextVar.inner); // previous instructions $0 = LoadLocal arr $1 = $0.map // Below instructions are synthetic $2 = LoadLocal contextVar $3 = $2.inner $4 = Function deps=$3 context=contextVar { ... } ``` - a few changes are effectively bugfixes (see `aliased-nested-scope-fn-expr`) --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32096). * #32099 * #32286 * #32104 * #32098 * #32097 * __->__ #32096
(needs cleanup) - Scopes no longer store a flat list of their dependencies. Instead: - Scope terminals are effectively a `goto` for scope dependency instructions (represented as value blocks that terminate with a `goto scopeBlock` for HIR and a series of ReactiveInstructions for ReactiveIR) - Scopes themselves store `dependencies: Array<Place>`, which refer to temporaries written to by scope dependency instructions Next steps: - new pass to dedupe scope dependency instructions after all dependency and scope pruning passes, effectively 'hoisting' dependencies out - more complex dependencies (unary ops like `Boolean` or `Not`, binary ops like `!==` or logical operators)
Inferred effect dependencies now include optional chains. This is a temporary solution while #32099 and its followups are worked on. Ideally, we should model reactive scope dependencies in the IR similarly to `ComputeIR` -- dependencies should be hoisted and all references rewritten to use the hoisted dependencies. (will add more test cases)
Inferred effect dependencies now include optional chains. This is a temporary solution while #32099 and its followups are worked on. Ideally, we should model reactive scope dependencies in the IR similarly to `ComputeIR` -- dependencies should be hoisted and all references rewritten to use the hoisted dependencies. (will add more test cases)
Inferred effect dependencies now include optional chains. This is a temporary solution while #32099 and its followups are worked on. Ideally, we should model reactive scope dependencies in the IR similarly to `ComputeIR` -- dependencies should be hoisted and all references rewritten to use the hoisted dependencies. `
When collecting scope dependencies, mark each dependency with `reactive: true | false`. This prepares for later PRs #33326 and #32099 which rewrite scope dependencies into instructions. Note that some reactive objects may have non-reactive properties, but we do not currently track this. Technically, state[0] is reactive and state[1] is not. Currently, both would be marked as reactive. ```js const state = useState(); ```
Inferred effect dependencies now include optional chains. This is a temporary solution while #32099 and its followups are worked on. Ideally, we should model reactive scope dependencies in the IR similarly to `ComputeIR` -- dependencies should be hoisted and all references rewritten to use the hoisted dependencies. `
Inferred effect dependencies now include optional chains. This is a temporary solution while #32099 and its followups are worked on. Ideally, we should model reactive scope dependencies in the IR similarly to `ComputeIR` -- dependencies should be hoisted and all references rewritten to use the hoisted dependencies. `
Inferred effect dependencies now include optional chains. This is a temporary solution while #32099 and its followups are worked on. Ideally, we should model reactive scope dependencies in the IR similarly to `ComputeIR` -- dependencies should be hoisted and all references rewritten to use the hoisted dependencies. `
Inferred effect dependencies now include optional chains. This is a temporary solution while #32099 and its followups are worked on. Ideally, we should model reactive scope dependencies in the IR similarly to `ComputeIR` -- dependencies should be hoisted and all references rewritten to use the hoisted dependencies. `
Inferred effect dependencies now include optional chains. This is a temporary solution while #32099 and its followups are worked on. Ideally, we should model reactive scope dependencies in the IR similarly to `ComputeIR` -- dependencies should be hoisted and all references rewritten to use the hoisted dependencies. `
When collecting scope dependencies, mark each dependency with `reactive: true | false`. This prepares for later PRs #33326 and #32099 which rewrite scope dependencies into instructions. Note that some reactive objects may have non-reactive properties, but we do not currently track this. Technically, state[0] is reactive and state[1] is not. Currently, both would be marked as reactive. ```js const state = useState(); ```
When collecting scope dependencies, mark each dependency with `reactive: true | false`. This prepares for later PRs #33326 and #32099 which rewrite scope dependencies into instructions. Note that some reactive objects may have non-reactive properties, but we do not currently track this. Technically, state[0] is reactive and state[1] is not. Currently, both would be marked as reactive. ```js const state = useState(); ``` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33325). * #33326 * __->__ #33325 * #32286
…33326) Inferred effect dependencies now include optional chains. This is a temporary solution while #32099 and its followups are worked on. Ideally, we should model reactive scope dependencies in the IR similarly to `ComputeIR` -- dependencies should be hoisted and all references rewritten to use the hoisted dependencies. ` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33326). * __->__ #33326 * #33325 * #32286
…33326) Inferred effect dependencies now include optional chains. This is a temporary solution while #32099 and its followups are worked on. Ideally, we should model reactive scope dependencies in the IR similarly to `ComputeIR` -- dependencies should be hoisted and all references rewritten to use the hoisted dependencies. ` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33326). * __->__ #33326 * #33325 * #32286 DiffTrain build for [0d07288](0d07288)
(needs cleanup)
goto
for scope dependency instructions (represented as value blocks that terminate with agoto scopeBlock
for HIR and a series of ReactiveInstructions for ReactiveIR)dependencies: Array<Place>
, which refer to temporaries written to by scope dependency instructionsNext steps:
Boolean
orNot
, binary ops like!==
or logical operators)Stack created with Sapling. Best reviewed with ReviewStack.