[MIPS][MSA] Invert operand order of ILVOD when lowering VECTOR_SHUFFLE
#123555
+7
−7
Conversation
This file contains hidden or 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
The result was <y[1], x[1]> while it should be <x[1], y[1]>.
This affects the result of vector shuffles:
%result = shufflevector <4 x i32> %x, <4 x i32> %y,
<4 x 132> <i32 1, i32 5, i32 3, i32 7>
The mask above matches the pattern wanted by the ILVOD lowering.
The result is <%y[1], %x[1], %y[3], %x[3]>, while it should be
<%x[1], %y[1], %x[3], %y[3]>.
* tests/CodeGen/Mips: Update MSA shuffle tests according to the change.
|
@wzssyqa I have split the change as per your request - please continue your review here. Thanks! |
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.
This PR fixes operand order of
ILVOD.dfwhen loweringVECTOR_SHUFFLE, the result was<y[1], x[1]>while it should be<x[1], y[1]>.Background
Our Rust toolchain has a long-standing bug that stood unresolved:
sha2::compress256produces a wrong result if MSA is enabled.Recently @liushuyu presented me with a minimal IR that can reproduce the problem, and here's the fix.
Testing
I have tested the patch with:
sha2::compress256These tests looks good to me.
compress256, compiled by the toolchain without the fix