Skip to content

Conversation

@kripken
Copy link
Member

@kripken kripken commented Apr 9, 2024

"Generative" is what we call something like a struct.new that may be syntactically
identical to another struct.new, but each time a new value is generated. The same
is true for calls, which can do anything, including return a different value for
syntactically identical calls.

This was not a bug because the main user of isGenerative,
areConsecutiveInputsEqual(), was too weak to notice, that is, it gave up sooner,
for other reasons. This PR improves that function to do a much better check,
which makes the fix necessary to prevent regressions.

This is not terribly important for itself, but will help a later PR that will add code
that depends more heavily on areConsecutiveInputsEqual().

@kripken kripken requested a review from tlively April 9, 2024 21:34
struct Scanner : public PostWalker<Scanner> {
bool generative = false;

void visitCall(Call* curr) { generative = true; }
Copy link
Member

Choose a reason for hiding this comment

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

Can we see if the callee has side effects here? If it doesn't, then it must be pure and we know it can't be generative. (Unless we're missing generativity itself as a side effect?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point that we could do better here, I'll add a TODO. Effects are not enough, though: imagine the body is a struct.new, that has no effects but it is generative. So we'd need to recursively check the generativity property.

))

;; But generative effects in the fallthrough values themselves block us.
(drop (f64.abs
Copy link
Member

Choose a reason for hiding this comment

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

It would be nice to put each of these cases in its own function so that it appears adjacent to its output in the test file.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

Comment on lines 14881 to 14883
(call $set-i32
(i32.const 1337)
)
Copy link
Member

Choose a reason for hiding this comment

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

Does the code do the right thing if this is a local.set $x so the "matching" tee and get are not matching after all?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, that was wrong. Fixed now and added testing.

Copy link
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

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

LGTM!

@kripken kripken merged commit 111902d into WebAssembly:main Apr 11, 2024
@kripken kripken deleted the gen.opt branch April 11, 2024 23:41
@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