This patch make the following optimization.
(mul x, 3 * power_of_2) -> (SLLI (SH1ADD x, x), bits) (mul x, 5 * power_of_2) -> (SLLI (SH2ADD x, x), bits) (mul x, 9 * power_of_2) -> (SLLI (SH3ADD x, x), bits)
Details
Details
Diff Detail
Diff Detail
Unit Tests
Unit Tests
Event Timeline
Comment Actions
The new optimization rules must be put before the following generic SH*ADD rules, otherwise the new optimization does not work.
def : Pat<(add (shl GPR:$rs1, (XLenVT 1)), non_imm12:$rs2),
(SH1ADD GPR:$rs1, GPR:$rs2)>;
def : Pat<(add (shl GPR:$rs1, (XLenVT 2)), non_imm12:$rs2),
(SH2ADD GPR:$rs1, GPR:$rs2)>;
def : Pat<(add (shl GPR:$rs1, (XLenVT 3)), non_imm12:$rs2),
(SH3ADD GPR:$rs1, GPR:$rs2)>;Comment Actions
For previous Pats, such as
def : Pat<(add (mul_oneuse GPR:$rs1, (XLenVT 12)), GPR:$rs2),
(SH2ADD (SH1ADD GPR:$rs1, GPR:$rs1), GPR:$rs2)>;The pattern (rs1*12 + rs2) no long existed after changes in decomposeMulByConstant(), so it has to be changed to
ParFrag<shadd ...>
def : Pat<(shadd GPR:$rs1, (XLenVT 1), (XLenVT 2), non_imm12:$rs2),
(SH1ADD (SH1ADD GPR:$rs1, GPR:$rs1), GPR:$rs2)>;to preserve the previous optimization.
What's more, they must be put before the generic rs1*2+rs2->(shadd rs1, rs2) ones otherwise they can not be matched.
| llvm/lib/Target/RISCV/RISCVInstrInfoB.td | ||
|---|---|---|
| 972–977 | To be, shadd means something like A << B + C, not A << B + A << C + D | |
| llvm/lib/Target/RISCV/RISCVInstrInfoB.td | ||
|---|---|---|
| 972–977 | change the ParFrag's name to addshl. | |
| llvm/lib/Target/RISCV/RISCVInstrInfoB.td | ||
|---|---|---|
| 972–977 | If I understand it correctly, But on spec those patterns are: uint_xlen_t sh1add(uint_xlen_t rs1, uint_xlen_t rs2)
{
return (rs1 << 1) + rs2;
}
uint_xlen_t sh2add(uint_xlen_t rs1, uint_xlen_t rs2)
{
return (rs1 << 2) + rs2;
}
uint_xlen_t sh3add(uint_xlen_t rs1, uint_xlen_t rs2)
{
return (rs1 << 3) + rs2;
} | |
| llvm/lib/Target/RISCV/RISCVInstrInfoB.td | ||
|---|---|---|
| 972–977 | Nevermind...missed the update | |
Comment Actions
I did not put the optimization of (mul x, 3 * power_of_2) in decomposeMulByConstant(). The reason is that using a PatLeaf is more simple than checking the pattern (ADD (SLLI), (SLLI).
Comment Actions
I change the $rs2 in the Pat from non_imm12 to GPR as following
def : Pat<(addshl GPR:$rs1, (XLenVT 1), (XLenVT 2), GPR:$rs2),
(SH1ADD (SH1ADD GPR:$rs1, GPR:$rs1), GPR:$rs2)>;Because for a*6 + 10, non_imm12:$rs2 will lead to
addi Rb, zero, 6 mul Ra, Rb, Ra addi Ra, Ra, 6
while GPR:$rs2 will lead to
addi Rb, zero, 10 sh1add Ra, Ra, Ra sh1add Ra, Ra, Rb
And I think the later one is better, so I changed non_imm12:$rs2 to GPR:$rs2.
Comment Actions
I'm not sure I follow this. How can a change to the isel pattern cause a mul to be created? Wasn't the mul already decomposed?
This comment was removed by benshi001.
Comment Actions
You are right. For non_imm12:$rs2 in a*10+6, the following is generated
slli a1, a0, 1 sh3add a0, a0, a1 addi a0, a0, 6
For GPR:$rs2, the assembly is
sh2add a0, a0, a0 addi a1, zero, 6 sh1add a0, a0, a1
I think maybe the first one is better, so I will rollback my patch.
This comment was removed by benshi001.
Comment Actions
I have split previous patch to smaller ones, which would be easy to review. And current patch only contains
(mul x, 3 * power_of_2) -> (SLLI (SH1ADD x, x), bits) (mul x, 5 * power_of_2) -> (SLLI (SH2ADD x, x), bits) (mul x, 9 * power_of_2) -> (SLLI (SH3ADD x, x), bits)
| llvm/lib/Target/RISCV/RISCVInstrInfoB.td | ||
|---|---|---|
| 1001 | Can we rename BSETINVTwoBitsMaskLow to TrailingZerosXForm? | |
Comment Actions
Since it does 63-leadingzeros i wouldn’t name it LeadingZerosXForm. You can leave it as is until we find another use for it.
To be, shadd means something like A << B + C, not A << B + A << C + D