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

x64: Add shuffle specialization for palignr #5999

Merged
merged 2 commits into from
Mar 13, 2023

Conversation

alexcrichton
Copy link
Member

This commit adds specializations for the palignr instruction to the x64 backend to specialize some more patterns of byte shuffles.

@github-actions github-actions bot added cranelift Issues related to the Cranelift code generator cranelift:area:x64 Issues related to x64 codegen isle Related to the ISLE domain-specific language labels Mar 12, 2023
@github-actions
Copy link

Subscribe to Label Action

cc @cfallin, @fitzgen

This 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:

  • cfallin: isle
  • fitzgen: isle

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

(xmm_rm_r_imm (SseOpcode.Palignr)
src1
src2
imm
size))
(rule 1 (x64_palignr src1 src2 imm size)
(OperandSize.Size32)))
Copy link
Member

Choose a reason for hiding this comment

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

Why this change? Why always 32?

Copy link
Member

Choose a reason for hiding this comment

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

I guess it was always passed 32, but I'm still a little confused why it was like that.

Copy link
Member Author

Choose a reason for hiding this comment

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

@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.

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 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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

@alexcrichton alexcrichton added this pull request to the merge queue Mar 13, 2023
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Mar 13, 2023
This commit adds specializations for the `palignr` instruction to the
x64 backend to specialize some more patterns of byte shuffles.
@alexcrichton alexcrichton added this pull request to the merge queue Mar 13, 2023
Merged via the queue into bytecodealliance:main with commit e2a6fe9 Mar 13, 2023
@alexcrichton alexcrichton deleted the palignr branch March 13, 2023 21:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift:area:x64 Issues related to x64 codegen cranelift Issues related to the Cranelift code generator isle Related to the ISLE domain-specific language
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants