[flang-commits] [flang] [mlir] [MLIR] Add cpow support in ComplexToROCDLLibraryCalls (PR #153183)

[Akash Banerjee via flang-commits]

================
@@ -56,10 +56,43 @@ struct ComplexOpToROCDLLibraryCalls : public OpRewritePattern<Op> {
 private:
   std::string funcName;
 };
+
+// Rewrite complex.pow(z, w) -> complex.exp(w * complex.log(z))
+struct PowOpToROCDLLibraryCalls : public OpRewritePattern<complex::PowOp> {
+  using OpRewritePattern<complex::PowOp>::OpRewritePattern;
+
+  LogicalResult matchAndRewrite(complex::PowOp op,
+                                PatternRewriter &rewriter) const final {
+    auto loc = op.getLoc();
+    if (auto constOp = op.getRhs().getDefiningOp<complex::ConstantOp>()) {
+      ArrayAttr value = constOp.getValue();
+      if (value.size() == 2) {
+        auto real = dyn_cast<FloatAttr>(value[0]);
+        auto imag = dyn_cast<FloatAttr>(value[1]);
+        if (real && imag && imag.getValue().isZero())
+          for (int i = 2; i <= 8; ++i)
----------------
TIFitis wrote:

Well, `cpow(x, 2.0+0i) => cmul(x, x)` isn't IEE bit equivalent. And, I am by no means an expert on fmath optimisations and how they are handled, so these optimisations might very well already be implemented somewhere in the chain for specific opt flag/target combinations. But I'm not sure about that.

We could move this optimisation to the front end lowering or somewhere else where it can be applied more broadly, and I'd be happy to do so if you want. But, I'm not sure if we should do that, your call :)

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