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

Revert "Stop propagating/inlining string constants (#6234)" #6258

Merged
merged 1 commit into from
Jan 31, 2024

Conversation

kripken
Copy link
Member

@kripken kripken commented Jan 30, 2024

This reverts commit 9090ce5.

Disallowing such optimization prevents e.g. string.eq from being
optimized out, if doing so depended on propagating constants to its arms.
Instead, to fix the real problem here, #6257 adds a pass that is run at the
end to collect string.const to globals. What will happen in practice is that
we propagate strings as we optimize, then at the end we collect them.

cc @gkdn - do you have thoughts on what order should these PRs land?

@kripken kripken requested a review from tlively January 30, 2024 22:19
@kripken kripken mentioned this pull request Jan 30, 2024
@gkdn
Copy link
Contributor

gkdn commented Jan 31, 2024

@kripken I think it would be best to avoid submitting this until we can complete the switch to imported string otherwise it would cause regression. (We cannot do the production switch until latest Chrome changes hit stable plus couple of weeks)

@gkdn
Copy link
Contributor

gkdn commented Jan 31, 2024

Sorry I think I misunderstood the other patch; let me do another pass with a clean mind later on.

@gkdn
Copy link
Contributor

gkdn commented Jan 31, 2024

Just to double check my understanding:
StringGathering pass will move all string.const to globals and will be running by part of O2.
Then later you will add additional pass which will be flag controlled to lower strings to imports.

When the other pass is added, will there be a benefit of running StringGathering as part of optimization loop vs. just running behind the scenes as part of the lowering pass that we will run once at the end?

Or is this just a temporary state so we can get the benefits of propagation without regression until we switch to imported strings?

Ordering wise seems like should we submit #6257 first?

@kripken
Copy link
Member Author

kripken commented Jan 31, 2024

@gkdn

When the other pass is added, will there be a benefit of running StringGathering as part of optimization loop vs. just running behind the scenes as part of the lowering pass that we will run once at the end?

It will not be needed at that time, correct. We might still keep it around because other toolchains might not run the other pass at the end, and in that case it would still help.

Ordering wise seems like should we submit #6257 first?

Agreed, yeah. Then when we land the reversion we won't get a regression.

Sound good to land them now, in that order?

@gkdn
Copy link
Contributor

gkdn commented Jan 31, 2024

Sounds good.

@kripken kripken merged commit b593849 into WebAssembly:main Jan 31, 2024
14 checks passed
@kripken kripken deleted the revert.string branch January 31, 2024 22:31
radekdoulik pushed a commit to dotnet/binaryen that referenced this pull request Jul 12, 2024
WebAssembly#6258)

This reverts commit 9090ce5.

This has the effect of once more propagating string constants from
globals to other places (and from non-globals too), which is useful
for various optimizations even if it isn't useful in the final output.
To fix the final output problem, WebAssembly#6257 added a pass that is run at the
end to collect string.const to globals, which allows us to once more
propagate strings in the optimizer, now without a downside.
@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.

3 participants