Skip to content

Conversation

@stevenfontanella
Copy link
Member

@stevenfontanella stevenfontanella commented Jan 1, 2026

Resolves the TODO is global-get-init.wast. Previously if a global was imported it would stop us from evaluating almost anything (?). After this change, an imported global doesn't prevent us from optimizing as long as the global isn't referenced in the constructor that we're targeting.

Part of #8180.

@stevenfontanella stevenfontanella force-pushed the allow-global-imports branch 2 times, most recently from 084a2f8 to 15ed8c6 Compare January 1, 2026 02:08
stevenfontanella added a commit that referenced this pull request Jan 7, 2026
Add an ImportResolver interface with some implementations to handle the
spec interpreter and ctor-eval

* Removes coupling of imported names from the module they come from.
This will allows us to provide special imports like the spec test module
better which have some 'magic' e.g. for printing functions which can't
be implemented in Wasm (globals remain the same because they still come
from a real module which is better).
* Removes pointer chasing logic when resolving imported globals in both
cases.
* Also allows us to relax ctor-eval and allow programs that import
globals to be optimized more (as long as they don't try to evaluate
imports) #8168
* Fixes #8167
* Part of #8180
Base automatically changed from global-import to main January 7, 2026 21:09
@stevenfontanella stevenfontanella changed the title Try allowing globals to be imported in ctor eval Ctor-eval: Don't stop evaluating when an imported global isn't used Jan 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants