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

Add a pass to propagate global constants to other globals #6287

Merged
merged 9 commits into from
Feb 8, 2024

Conversation

kripken
Copy link
Member

@kripken kripken commented Feb 8, 2024

SimplifyGlobals already does this, so this is a subset of that pass, and does not
add anything new. It is useful for testing, however.

In particular it allows testing that we propagate subsequent globals in a single
pass, that is if one global reads from another and becomes constant, then it
can be propagated as well. SimplifyGlobals runs multiple passes so this always
worked, but with this pass we can test that we do it efficiently in one pass.

This will also be useful for comparing stringref to imported strings, as it
allows gathered strings to be propagated to other globals but not anywhere
else (which might have downsides).

Also add an additional test for simplify-globals that we do not get confused by
an unoptimizable global.get in the middle (see last part of diff) as suggested
by @tlively

@tlively tlively self-requested a review February 8, 2024 18:15
@@ -369,6 +369,9 @@ void PassRegistry::registerPasses() {
registerPass("print-stack-ir",
"print out Stack IR (useful for internal debugging)",
createPrintStackIRPass);
registerPass("propagate-globals-globally",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this use registerTestPass to avoid it showing up in the --help output if it is only useful for tests? Or is it sometimes useful outside of tests as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is useful also for comparing stringref to imported strings.

Comment on lines +676 to +678
// Apply globals to this value, which may turn it into a constant we can
// further propagate, or it may already have been one.
applyGlobals(global->init);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a bug fix. Which test case does it affect?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a bugfix, see the second paragraph above: This makes us slightly more efficient in SimplifyGlobals, but we always did it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tlively
Copy link
Member

tlively commented Feb 8, 2024

Oops, guess I should have read the description more closely. Thanks!

@kripken kripken merged commit 6e1e53f into WebAssembly:main Feb 8, 2024
14 checks passed
@kripken kripken deleted the prop.glob branch February 8, 2024 18:38
radekdoulik pushed a commit to dotnet/binaryen that referenced this pull request Jul 12, 2024
…y#6287)

SimplifyGlobals already does this, so this is a subset of that pass, and does not
add anything new. It is useful for testing, however.

In particular it allows testing that we propagate subsequent globals in a single
pass, that is if one global reads from another and becomes constant, then it
can be propagated as well. SimplifyGlobals runs multiple passes so this always
worked, but with this pass we can test that we do it efficiently in one pass.

This will also be useful for comparing stringref to imported strings, as it
allows gathered strings to be propagated to other globals (possible with
stringref, but not imported strings) but not anywhere else (which might have
downsides as it could lead to more allocations).

Also add an additional test for simplify-globals that we do not get confused by
an unoptimizable global.get in the middle (see last part).
@gkdn gkdn mentioned this pull request Aug 31, 2024
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