================ @@ -8944,6 +8944,146 @@ static bool optimizeBranch(CondBrInst *Branch, const TargetLowering &TLI, return false; } +// Performs very basic loop strength reduction to vector values with a known +// evolution from one iteration to the next that are used as the value operand +// for a store. +// A simple example to illustrate: +// +// %vec.ind = phi <vscale x 2 x i64> [ %start, %entry ], +// [ %vec.ind.next, %vector.body ] +// %data.gep = getelementptr inbounds nuw [72 x i8], ptr %datap, +// <vscale x 2 x i64> %vec.ind +// %addr.gep = getelementptr inbounds nuw [8 x i8], ptr %addrp, i64 %index +// store <vscale x 2 x ptr> %data.gep, ptr %addr.gep, align 8 +// %vec.ind.next = add nuw nsw <vscale x 2 x i64> %vec.ind, %elt.cnt.splat +// +// This will end up with a multiply by a vscale-scaled term in the loop, as +// well as adding to the base. Changing it to add a splat based on vscale * +// min.elt.cnt * sizeof(ptrdiff) and remove the gep removes the multiply. ---------------- huntergr-arm wrote:
Yes, that's where the vscale comes from. The GEP is responsible for the multiply. The PHI effectively holds the scalar iteration numbers (0, 1, 2, ....), and the GEP is generated as a multiply of that by the size of the struct (in this case, 72 bytes) and an add to the splat of the base. So you're right in that the vscale isn't particularly interesting wrt. the multiply, but when I originally looked at the code for SVE vs. NEON, the NEON version had folded away the multiplies due to it being fixed width, whereas we couldn't do that with scalable vectors. That said, Sander came up with a very similar reproducer for NEON, so this optimization is more broadly applicable than I first thought. https://godbolt.org/z/e7s74oohr shows shifts being used for fixed width. https://github.com/llvm/llvm-project/pull/226197 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
