cranelift: Bitwise compare fuzzgen results #4855
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jameysharp
approved these changes
Sep 2, 2022
Comment on lines
+58
to
+61
| && actual | ||
| .into_iter() | ||
| .zip(expected.into_iter()) | ||
| .all(|(a, b)| a.bitwise_eq(b)); |
There was a problem hiding this comment.
For future reference, it's possible to write this more tersely. Iterator::zip will implicitly call into_iter() on whatever you pass to it, so you can just use .zip(expected). And the implementation of into_iter() on &Vec is the same as calling iter() (they both return references to the elements of the vector) so you can use the shorter name. When I was playing with this locally I found that those two changes meant this part of the expression would fit on one line with cargo fmts defaults. 😁
This is not remotely important, so I'm merging without that change and please don't bother writing another PR for it. This version is just fine as-is. But I thought I'd note the alternative.
jameysharp
added a commit
to jameysharp/wasmtime
that referenced
this pull request
Sep 2, 2022
This fixes bytecodealliance#4857 by partially reverting bytecodealliance#4849. It turns out that Ieee32 and Ieee64 need bitwise equality semantics so they can be used as hash-table keys. Moving the IEEE754 semantics up a layer to DataValue makes sense in conjunction with bytecodealliance#4855, where we introduced a DataValue::bitwise_eq alternative implementation of equality for those cases where users of DataValue still want the bitwise equality semantics.
jameysharp
added a commit
that referenced
this pull request
Sep 3, 2022
* cranelift-codegen: Remove all uses of DataValue This type is only used by the interpreter, cranelift-fuzzgen, and filetests. I haven't found another convenient crate for those to all depend on where this type can live instead, but this small refactor at least makes it obvious that code generation does not in any way depend on the implementation of this type. * Make DataValue, not Ieee32/64, respect IEEE754 This fixes #4857 by partially reverting #4849. It turns out that Ieee32 and Ieee64 need bitwise equality semantics so they can be used as hash-table keys. Moving the IEEE754 semantics up a layer to DataValue makes sense in conjunction with #4855, where we introduced a DataValue::bitwise_eq alternative implementation of equality for those cases where users of DataValue still want the bitwise equality semantics. * cranelift-interpreter: Use eq/ord from DataValue This fixes #4828, again, now that the comparison operators on DataValue have the right IEEE754 semantics. * Add regression test from issue #4857
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
cc: 4849
cc: @jameysharp