Skip to content

Remove bulk memory instructions refering to active segments #2235

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

Merged
merged 3 commits into from
Jul 19, 2019

Conversation

tlively
Copy link
Member

@tlively tlively commented Jul 19, 2019

This prevents those instructions from becoming invalid due to memory
packing optimizations and is also a code size win. Fixes #2227.

This prevents those instructions from becoming invalid due to memory
packing optimizations and is also a code size win. Fixes WebAssembly#2227.
@tlively tlively requested a review from kripken July 19, 2019 00:14
void process(Expression* curr, Index index) {
if (!getModule()->memory.segments[index].isPassive) {
ExpressionManipulator::unreachable(curr);
}
Copy link
Member

Choose a reason for hiding this comment

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

Isn't it already a validation error to call memory.init or memory.drop on active segments?

Copy link
Member Author

@tlively tlively Jul 19, 2019

Choose a reason for hiding this comment

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

Nope, for some reason that is valid but traps (because the segments were dropped during initialization). According the bulk memory proposal's overview.md, anyway.

Copy link
Member

Choose a reason for hiding this comment

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

Oh I see. I guess that is because validation is done with only the information in the data count section which is not enough to know about the active/passive status of as segment. Otherwise it would make sense to be a validation error.

Why would we ever expect to have such instruction in the input? Perhaps binaryen could make this a hard error rather than delaying the error until runtime?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah I briefly discussed the possibility of making this a binaryen validation error with @kripken, but I don't believe we have precedent for Binaryen rejecting valid wasm modules, even if they do silly things. We decided this would be better because it still accepts all valid modules and is a nice size optimization, too.

Copy link
Member

Choose a reason for hiding this comment

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

I opened WebAssembly/bulk-memory-operations#107 to get some clarifation, but I guess its too late to change DataCount section now.


void optimizeTrappingBulkMemoryOps(Module* module) {
struct Trapper : PostWalker<Trapper> {
bool changed = false;
Copy link
Member

Choose a reason for hiding this comment

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

no need for this assignment

@@ -120,6 +124,28 @@ struct MemoryPacking : public Pass {
}
module->memory.segments.swap(packed);
}

void optimizeTrappingBulkMemoryOps(Module* module) {
struct Trapper : PostWalker<Trapper> {
Copy link
Member

Choose a reason for hiding this comment

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

it's not urgent but this should be parallelized. please add at least a TODO about that

} trapper;
trapper.walkModule(module);
trapper.run(runner, module);
Copy link
Member

Choose a reason for hiding this comment

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

this is confusing actually - this just does the normal walk. I should add an assertion about it. To parallelize you need to create a PassRunner, add the pass, and run that. Should also set isNested. See for example Inlining which has nested passes.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh oops lol

@tlively
Copy link
Member Author

tlively commented Jul 19, 2019

@kripken is this good to go with your separate changes to make run automatically parallelize passes?

@kripken
Copy link
Member

kripken commented Jul 19, 2019

Yes, lgtm!

@tlively tlively merged commit 72c52ea into WebAssembly:master Jul 19, 2019
@kripken
Copy link
Member

kripken commented Jul 20, 2019

@tlively this broke tests when it landed, stuff like

[PassRunner] running passes...
[PassRunner]   running pass: memory-packing... 3.6999e-05 seconds.
[PassRunner]   (validating)
[wasm-validator error in function $foo] stale type found in $foo on 0xc75b58
(marked as none, should be unreachable)

Oddly it didn't fail in your PR, not sure why.

@tlively
Copy link
Member Author

tlively commented Jul 20, 2019

Gross, it was probably a bad merge interaction with something else that landed. I’ll revert and debug.

tlively added a commit that referenced this pull request Jul 20, 2019
tlively added a commit that referenced this pull request Jul 20, 2019
…2235)" (#2244)

This reverts commit 72c52ea, which was causing test failures after it merged.
tlively added a commit that referenced this pull request Jul 21, 2019
#2242 had exposed the bug that the `Trapper` pass was defining `walkFunction` when it should have been defining `doWalkFunction`.
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.

[fuzz testcase] "data.drop segment index out of bounds"
3 participants