x64: Refactor multiplication instructions#7871
Merged
abrown merged 3 commits intobytecodealliance:mainfrom Feb 9, 2024
Merged
Conversation
This commit is inspired after reading over some code from bytecodealliance#7865 and bytecodealliance#7866. The goal of this commit was to refactor scalar multiplication-related instructions in the x64 backend to more closely align with their native instructions. Changes include: * The `MulHi` instruction is renamed to `Mul`. This represents either `mul` or `imul` producing a doublewide result. * A `Mul8` instruction was added to correspond to `Mul` for the 8-bit variants that produce a doublewide result in the `AX` register rather than the other instructions which split between `RAX` and `RDX`. * The `UMulLo` instruction was removed as now it's covered by `Mul` * The `AluRmiROpcode::Mul` opcode was removed in favor of new `IMul` and `IMulImm` instructions. Register allocation and emission already had special cases for `Mul` which felt better as standalone instructions rather than putting in an existing variant. Lowerings using `imul` are not affected in general but the `IMulImm` instruction has different register allocation behavior than before which allows the destination to have a different register than the first operand. The `umulhi` and `smulhi` instructions are also reimplemented with their 8-bit variants instead of extension-plus-16-bit variants.
github-actions
bot
added
cranelift
These are all covered by the filetests framework now too.
Member
Author
|
cc @abrown you mentioned that you were also taking a look at this, want me to hold off on merging for that? |
Subscribe to Label ActionDetailsThis issue or pull request has been labeled: "cranelift", "cranelift:area:x64", "winch"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
Member
|
Nah, it's good to go now that @fitzgen looked at it. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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 commit is inspired after reading over some code from #7865 and #7866. The goal of this commit was to refactor scalar multiplication-related instructions in the x64 backend to more closely align with their native instructions. Changes include:
MulHiinstruction is renamed toMul. This represents eithermulorimulproducing a doublewide result.Mul8instruction was added to correspond toMulfor the 8-bit variants that produce a doublewide result in theAXregister rather than the other instructions which split betweenRAXandRDX.UMulLoinstruction was removed as now it's covered byMulAluRmiROpcode::Mulopcode was removed in favor of newIMulandIMulImminstructions. Register allocation and emission already had special cases forMulwhich felt better as standalone instructions rather than putting in an existing variant.Lowerings using
imulare not affected in general but theIMulImminstruction has different register allocation behavior than before which allows the destination to have a different register than the first operand. Theumulhiandsmulhiinstructions are also reimplemented with their 8-bit variants instead of extension-plus-16-bit variants.