As discussed in https://reviews.llvm.org/D62341#1515637,
for MIPS add %x, -1 isn't optimal. Unlike X86 there
are no fastpaths to matearialize such -1/1 vector constants,
and sub %x, 1 results in better codegen,
so undo canonicalization
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
This patch targets very specific values(1,-1) but there are more. The trick for D62341 is that msa vector add/sub imm accept 5 bit unsigned imm, so it is ok to switch from add imm to sub imm (also sub to add) if it changes imm form negative to positive. I think it is cleanest to have some hook and ask target if it would like to transform sub into add (add to sub) with imm.
Thank you for taking a look.
Yeah, i have found that in ISA manual since posting the patch.
I think it is cleanest to have some hook and ask target if it would like to transform sub into add (add to sub) with imm.
I understand where this is coming from but no, that will not be ok.
The whole point of D62341 is that we really don't want sub %x, C in DAGCombine,
so while we could hide it behind target hook, that defies the whole purpose.
So this needs to be undone per-target in *ISelDAGToDAG.cpp.
Forgot to mention, this sub %X, C -> add %X, -C transform is already always being performed
by InstCombine in middle-end, so such undo transform is needed regardless of what DAGCombine does.
Generalize the check, do not limit the transform to -1 specifically,
but rather all splat immediates if negating results in inline immediate (5-bit unsigned)
llvm/test/CodeGen/Mips/msa/arithmetic.ll | ||
---|---|---|
220–241 ↗ | (On Diff #218151) | Hm, this one didn't get recovered by the patch. |
llvm/test/CodeGen/Mips/msa/arithmetic.ll | ||
---|---|---|
220–241 ↗ | (On Diff #218151) | I saw this regression. Unfortunately I could not quickly create a fix for it. As far as I remember, the problem is in this statement auto *BVN = dyn_cast<BuildVectorSDNode>(C). In @sub_v2i64_i the second operand (i.e. C) is a bitcast and dyn_cast<BuildVectorSDNode> returns zero. Right now I do not have a time to dig it. Maybe next week. |
llvm/test/CodeGen/Mips/msa/arithmetic.ll | ||
---|---|---|
220–241 ↗ | (On Diff #218151) | Honestly i didn't notice that it didn't address all of the patterns until now. t10: v2i64 = add t7, t16 t7: v2i64,ch = load<(load 16 from %ir.a)> t0, t4, undef:i32 t4: i32,ch = CopyFromReg t0, Register:i32 %1 t3: i32 = Register %1 t6: i32 = undef t16: v2i64 = bitcast t15 t15: v4i32 = BUILD_VECTOR Constant:i32<-1>, Constant:i32<-31>, Constant:i32<-1>, Constant:i32<-31> t14: i32 = Constant<-1> t13: i32 = Constant<-31> t14: i32 = Constant<-1> t13: i32 = Constant<-31> So yes, this because of a bitcast. |