Skip to content
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

[compiler] Represent array accesses with PropertyLoad #32287

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft

Conversation

mofeiZ
Copy link
Contributor

@mofeiZ mofeiZ commented Feb 1, 2025

(draft, needs cleanup)

Prior to this PR, our HIR represented property access with numeric literals (e.g. myVar[0]) as ComputedLoads. This means that they were subject to some deopts (most notably, not being easily dedupable / hoistable as dependencies).

Now, PropertyLoad, PropertyStore, etc reference numeric and string literals (although not yet string literals that aren't valid babel identifiers). The difference between PropertyLoad and ComputedLoad is fuzzy now (maybe we should rename these).

  • PropertyLoad: property keys are string and numeric literals, only when the string literals are valid babel identifiers
  • ComputedLoad: non-valid babel identifier string literals (rare) and other non-literal expressions

The biggest feature from this PR is that it trivially enables array-indicing expressions as dependencies. The compiler can also specify global and imported types for arrays (e.g. return value of useState)

I'm happy to close this if it complicates more than it helps -- alternative options are to entirely rely on instruction reordering-based approaches like ReactiveGraphIR or make dependency-specific parsing + hoisting logic more robust.

Stack created with Sapling. Best reviewed with ReviewStack.

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.
This removes special casing for `PropertyStore` mutability inference within FunctionExpressions.
(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)
(draft, needs cleanup)

Prior to this PR, our HIR represented property access with numeric literals (e.g. `myVar[0]`) as ComputedLoads. This means that they were subject to some deopts (most notably, not being easily dedupable / hoistable as dependencies).

Now, `PropertyLoad`, `PropertyStore`, etc reference numeric and string literals (although not yet string literals that aren't valid babel identifiers). The difference between PropertyLoad and ComputedLoad is fuzzy now (maybe we should rename these).
- PropertyLoad: property keys are string and numeric literals, only when the string literals are valid babel identifiers
- ComputedLoad: non-valid babel identifier string literals (rare) and other non-literal expressions

The biggest feature from this PR is that it trivially enables array-indicing expressions as dependencies. The compiler can also specify global and imported types for arrays (e.g. return value of `useState`)


I'm happy to close this if it complicates more than it helps -- alternative options are to entirely rely on instruction reordering-based approaches like ReactiveGraphIR or make dependency-specific parsing + hoisting logic more robust.
@josephsavona
Copy link
Contributor

Didn’t look at the code yet but the idea makes totally sense. PropertyLoad for cases of a static property, ComputedLoad for where the index is dynamic. We might want to rename them in a follow up.

Caner452

This comment was marked as spam.

@josephsavona josephsavona requested review from Caner452 and removed request for Caner452 February 1, 2025 16:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed React Core Team Opened by a member of the React Core Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants