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

OptimizeInstructions: Add missing invalidation check in consecutive equality test #6596

Merged
merged 8 commits into from
May 15, 2024

Conversation

kripken
Copy link
Member

@kripken kripken commented May 15, 2024

This existed before #6495 but became noticeable there. We only looked at
the fallthrough values in the later part of areConsecutiveInputsEqual, but
there can be invalidation due to the non-fallthrough part:

(i32.add
  (local.get $x)
  (block
    (local.set $x ..)
    (local.get $x)
  )
)

The set can cause the local.get to differ the second time. To fix this,
check if the non-fallthrough part invalidates the fallthrough (but only
on the right hand side).

Fixes #6593

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 % question and nit.

;; CHECK-NEXT: (local $3 i32)
;; CHECK-NEXT: (drop
;; CHECK-NEXT: (block (result (ref $array))
;; CHECK-NEXT: (local.set $0
Copy link
Member

Choose a reason for hiding this comment

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

Why do we set this local if we never use it?

Copy link
Member Author

@kripken kripken May 15, 2024

Choose a reason for hiding this comment

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

The utility we use puts all children in locals. After that, they are all either local.gets or constants and we can reason about them easily. It does mean we depend on later passes to clean things up, but it saves complexity (that utility isn't aware of how we will use the children).

Copy link
Member

Choose a reason for hiding this comment

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

Makes sense, thanks.

Comment on lines +3531 to +3532
;; Still identical fallthroughs, but different effects now.
(drop
Copy link
Member

Choose a reason for hiding this comment

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

nit: it would be easier to compare the test input to the output if these were separate functions

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, I actually intentionally grouped them in batches of 4 very similar functions. Is 4 too many, do you think?

Copy link
Member

Choose a reason for hiding this comment

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

I had to do a bit of scrolling and hunting, but it wasn't so bad. There are certainly also advantages to grouping similar test cases.

Copy link
Member Author

Choose a reason for hiding this comment

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

Do you think it's worth splitting them any more, then? I feel it's reasonable but maybe 2 instead of 4 is another way to go here.

Copy link
Member

Choose a reason for hiding this comment

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

I think it's fine as-is.

@kripken kripken merged commit 2cc5e06 into WebAssembly:main May 15, 2024
13 checks passed
@kripken kripken deleted the array.new.fixed.dupe branch May 15, 2024 19:48
@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.

Bug in recent "OptimizeInstructions: Optimize StructNew/ArrayNew forms"
2 participants