================
@@ -908,19 +919,24 @@ multiclass IMAD32_Pats <VOP3_Pseudo inst> {
// Handle cases where amdgpu-codegenprepare-mul24 made a mul24 instead of a
normal mul.
// We need to separate this because otherwise OtherPredicates would be
overriden.
-class IMAD32_Mul24_Pat<VOP3_Pseudo inst>: GCNPat <
- (i64 (add (i64 (AMDGPUmul_u24 i32:$src0, i32:$src1)), i64:$src2)),
- (inst $src0, $src1, $src2, 0 /* clamp */)
- >;
+class IMAD32_Mul24_Pats_Impl<VOP3_Pseudo inst, SDPatternOperator AddOp, bit
mulIsRight = 0> : GCNPat <
+ !if(mulIsRight, (i64 (AddOp i64:$src2, (i64 (AMDGPUmul_u24 i32:$src0,
i32:$src1)))),
+ (i64 (AddOp (i64 (AMDGPUmul_u24 i32:$src0, i32:$src1)),
i64:$src2))),
----------------
ritter-x2a wrote:
What would be the behavior that we want from tablegen? Should the target be
able to specify "PTRADD should be considered commutative in tablegen'erated
ISel patterns"?
In general, PTRADD is not commutable, so treating it as commutable shouldn't be
the default. We can only treat it as commutable here because we know that we
are trying to lower it to an addition in this pattern.
We also don't want to treat PTRADD as commutable everywhere in the AMDGPU
backend since my goal with this effort is to check if to-be-folded immediate
offset additions are inbounds.
I'd prefer a solution that expresses that ptradds on AMDGPU should be folded
into the addressing mode, and if that's not possible, they should be replaced
by an ISD::ADD node and the ADD matching rules should be applied.
However, I haven't found a way to do that in the framework: Replacing
ISD::PTRADD with ISD::ADD sounds like a legalization or DAGCombine task, but
this shouldn't happen before the addressing mode is matched, which happens in
the proper selection phase.
https://github.com/llvm/llvm-project/pull/143881
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
