[llvm] [LoopIdiomRecognize] Enable clmul optimization for CRC loops (PR #203405)

[Sean Clarke via llvm-commits]

================
@@ -1582,6 +1590,164 @@ bool LoopIdiomRecognize::optimizeCRCLoop(const PolynomialInfo &Info) {
   if (TT.getArch() == Triple::hexagon)
     return false;
 
+  // In the clmul optimization, the first clmul uses 2*TC bits, and the second
+  // clmul uses CRCBW+TC bits. For simplicity, have both clmuls operate on the
+  // same bit width.
+  unsigned CRCBW = Info.LHS->getType()->getIntegerBitWidth();
+  unsigned ClmulBW = std::max(2 * Info.TripCount, CRCBW + Info.TripCount);
+  auto *ClmulTy = IntegerType::get(Info.LHS->getContext(), ClmulBW);
+
+  // The force-crc-clmul flag should cause the clmul optimization to run
+  // unconditionally.
+  if (ForceCRCClmul)
+    return optimizeCRCLoopUsingClmul(Info, ClmulTy) ||
+           (!ApplyCodeSizeHeuristics && optimizeCRCLoopUsingTableLookup(Info));
+
+  // FIXME: Once intrinsic cost modeling is more reliable for clmul, that should
+  // be used to determine which optimization to use. Until then, only apply the
+  // clmul optimization when optimizing for size, since a lookup table is not
+  // viable in that case.
+  if (!ApplyCodeSizeHeuristics)
+    return optimizeCRCLoopUsingTableLookup(Info);
+
+  // The clmul optimization should only be applied if clmul with the required
+  // bit width is a fast operation on the target.
+  // On some platforms, TC=8 for clmul seems to be slower than even the
+  // unoptimized loop, so bail on that case as well.
+  // TODO: If clmul exists on the target but not for the required width, it
+  // might be possible to split into multiple iterations of reduction.
+  if (Info.TripCount <= 8 || !TTI->haveFastClmul(ClmulTy))
----------------
xarkenz wrote:

Ah, fair point. I was worried that TC <= 8 would cause a performance regression, but with optsize, that's not as important.

https://github.com/llvm/llvm-project/pull/203405