-
Notifications
You must be signed in to change notification settings - Fork 12
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
[AIE2] Use OR to mimic MOV when copying GPR to GPR #221
Conversation
5617017
to
3e3143a
Compare
3fee812
to
10dafa6
Compare
|
@@ -94,6 +94,8 @@ let Itinerary = II_NE in { | |||
} | |||
let Itinerary = II_OR in { | |||
def OR : AIE2_alu_r_rr_inst_alu<0b0101, (outs eR:$mRx), (ins eR:$mRx0, eR:$mRy), "or", "$mRx, $mRx0, $mRy">; | |||
let isCodeGenOnly = 1 in | |||
def MOV_OR : AIE2_alu_r_rr_inst_alu_mov_gpr<0b0101, (outs eR:$mRx), (ins eR:$mRx0), "or", "$mRx, $mRx0, $mRx0">; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't mind defining this directly in terms of AIE2_inst_alu_instr32, computing the alu image here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @martien-de-jong kindly clarify on what you mean by "alu image". Thank you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let alu = {mRx0,mRx,mRx0,op,0b1};
as used in AIE2_alu_r_rr_inst_alu_mov_gpr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to be consistent with how all the other instructions are defined in the file.
If you think exposing alu
image here is better, I will update it :).
10dafa6
to
b22a5b9
Compare
b22a5b9
to
275b8c4
Compare
@@ -829,7 +838,8 @@ bool AIE2InstrInfo::expandPostRAPseudo(MachineInstr &MI) const { | |||
case AIE2::PseudoMove: { | |||
Register Dst = MI.getOperand(0).getReg(); | |||
Register Src = MI.getOperand(1).getReg(); | |||
BuildMI(MBB, MI, DL, get(AIE2::MOV_mv_scl), Dst) | |||
const unsigned MOVSclOpcode = getScalarMovOpcode(Dst, Src); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summarizing, this is 'late code selection' since the move is inserted by the register allocator. We check the registers here, and expand it to MOV_mv_scl immediately if there's no other way, or we expand it to a pseudo for which the scheduler decides whether to put in in MOV or in ALU.
I think it's fine, I'm just wondering whether the decision could already be made by RegAlloc to avoid this multi-stage expansion of pseudos.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just ping we if you want to still apply some of the comments.
I guess some regressions are unavoidable, but do we understand them?
Standalone this PR does not create regression, its the combination of #217 that leads to couple of cycles of regression. |
This PR allows to mimic MOV behavior using OR instr when MOV slot is not available.
Note : This works only when MOV was for GPR to GPR due to limitation of OR to only work with GPRs