- Notifications
You must be signed in to change notification settings - Fork 818
[NFC] Refactor ChildLocalizer to handle unreachable code better #6394
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| | @@ -925,3 +925,49 @@ | |
| (unreachable) | ||
| ) | ||
| ) | ||
| | ||
| (module | ||
| ;; CHECK: (rec | ||
| ;; CHECK-NEXT: (type $struct (sub (struct ))) | ||
| (type $struct (sub (struct (field anyref) (field i32) (field f32) (field f64)))) | ||
| | ||
| ;; CHECK: (type $1 (func (result (ref $struct)))) | ||
| | ||
| ;; CHECK: (func $func (type $1) (result (ref $struct)) | ||
| ;; CHECK-NEXT: (local $0 (ref $struct)) | ||
| ;; CHECK-NEXT: (local $1 f64) | ||
| ;; CHECK-NEXT: (local.set $0 | ||
| ;; CHECK-NEXT: (call $func) | ||
| ;; CHECK-NEXT: ) | ||
| ;; CHECK-NEXT: (local.set $1 | ||
| ;; CHECK-NEXT: (block (result f64) | ||
| ;; CHECK-NEXT: (if | ||
| ;; CHECK-NEXT: (i32.const 0) | ||
| ;; CHECK-NEXT: (then | ||
| ;; CHECK-NEXT: (unreachable) | ||
| ;; CHECK-NEXT: ) | ||
| ;; CHECK-NEXT: ) | ||
| ;; CHECK-NEXT: (f64.const 30) | ||
| ;; CHECK-NEXT: ) | ||
| ;; CHECK-NEXT: ) | ||
| ;; CHECK-NEXT: (struct.new_default $struct) | ||
| ;; CHECK-NEXT: ) | ||
| (func $func (result (ref $struct)) | ||
| ;; The fields can be removed here, but the effects must be preserved before | ||
| ;; the struct.new. The consts in the middle can vanish entirely. | ||
| Comment on lines +956 to +957 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do we try to handle unreachability at all in GTO when a --dce before hand would have the same effect? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note that this test does not have unreachability (only conditionally - but nothing unreachable reaches the We do want to handle unreachability in #6395. The situation there is that it is just simpler to allow removing unreachable code too (once we have done the other work in that PR to handle non-unreachable effects). | ||
| (struct.new $struct | ||
| (call $func) | ||
| (i32.const 10) | ||
| (f32.const 20) | ||
| (block (result f64) | ||
| (if | ||
| (i32.const 0) | ||
| (then | ||
| (unreachable) | ||
| ) | ||
| ) | ||
| (f64.const 30) | ||
| ) | ||
| ) | ||
| ) | ||
| ) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the parent is needed for validation like the post-unreachable children? For example it could be a
br_ifwhere the condition is unreachable but where it is the only reason its target block has type none.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. That is not an issue atm as it is called on things that do not have that behavior, but the user needs to be aware of that. I'll add a note.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(added)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be safer to just include the parent and let later DCE clean it up?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The caller needs to remove this code in some cases, and doing it there would be parsing the output from here to see if it is a block, and then checking if there is an unreachable child, and then removing the last block element if so (edit: and refinalizing). Then seems more complex to me.