[PATCH] D52977: [RISCV] Introduce codegen patterns for instructions introduced in RV64I
Alex Bradbury via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Oct 8 07:56:13 PDT 2018
asb added a comment.
There's one aspect I'd appreciate some input on. Full coverage of sext/zext/aext inputs and sext/aext outputs would require a lot of repetitive tests. But these tests would have value. e.g. to generate srlw for the following two functions:
define i32 @srlw(i32 signext %a, i32 zeroext %b) {
%1 = lshr i32 %a, %b
ret i32 %1
}
define signext i32 @srlw_sext(i32 signext %a, i32 zeroext %b) {
%1 = lshr i32 %a, %b
ret i32 %1
}
It's necessary to define two patterns:
def : Pat<(srl (zexti32 GPR:$rs1), GPR:$rs2),
(SRLW GPR:$rs1, GPR:$rs2)>;
def : Pat<(sext_inreg (srl (zexti32 GPR:$rs1), GPR:$rs2), i32),
(SRLW GPR:$rs1, GPR:$rs2)>;
zexti32 is defined to help two possible forms of inputs:
def zexti32 : PatFrags<(ops node:$src),
[(and node:$src, 0xffffffff), (assertzext node:$src)],
[{
if (N->getOpcode() == ISD::AssertZext) {
return cast<VTSDNode>(N->getOperand(1))->getVT() == MVT::i32;
}
return N->getOpcode() == ISD::AND;
}]>;
Does anyone have any views on the testing approach for the patterns for `*W` instructions? It would obviously be easy to programmatically generate all {aext,sext} return + {aext,sext,zext},{aext,sext,zext} operand variants, but this seems excessive. On the other hand, my experience has been that it is easy to unexpectedly find that the `*W` instruction you expected isn't being selected.
https://reviews.llvm.org/D52977
More information about the llvm-commits
mailing list