x64: Add shuffle specialization for palignr#5999
Conversation
github-actions
Bot
added
cranelift
Subscribe to Label ActionDetailsThis issue or pull request has been labeled: "cranelift", "cranelift:area:x64", "isle"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
| imm | ||
| size)) | ||
| (rule 1 (x64_palignr src1 src2 imm size) | ||
| (OperandSize.Size32))) |
There was a problem hiding this comment.
Why this change? Why always 32?
There was a problem hiding this comment.
I guess it was always passed 32, but I'm still a little confused why it was like that.
There was a problem hiding this comment.
@abrown do you perhaps remember why palignr was always generated with OperandSize.Size32? I'll admit I don't fully understand how OperandSize maps to instructions all the time but I naively figured that it could be "constant folded" into the palignr constructor, but a double-check would be good.
There was a problem hiding this comment.
Ah I remember now actually, this has to do with the rex flags when encoding where a 64-bit size forces the W bit to be set and otherwise W is unset. I believe the encoding of the palignr instruction forces this to "unset" so for palignr it should always be a non-64-bit size.
There was a problem hiding this comment.
Yeah, I think that sounds right. The OperandSize isn't my invention and I recall having to work around it--I think things would be more clear if we hid OperandSize completely or alternately surfaced it as REX.W, which is more direct.
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
This commit adds specializations for the `palignr` instruction to the x64 backend to specialize some more patterns of byte shuffles.
3 participants
This commit adds specializations for the
palignrinstruction to the x64 backend to specialize some more patterns of byte shuffles.