[flang-commits] [flang] [flang] IEEE_SCALB and SCALE - kind=2, kind=3 (PR #135374)

[via flang-commits]

================
@@ -7593,12 +7593,46 @@ IntrinsicLibrary::genSameTypeAs(mlir::Type resultType,
 mlir::Value IntrinsicLibrary::genScale(mlir::Type resultType,
                                        llvm::ArrayRef<mlir::Value> args) {
   assert(args.size() == 2);
+  mlir::FloatType floatTy = mlir::dyn_cast<mlir::FloatType>(resultType);
+  if (!floatTy.isF16() && !floatTy.isBF16()) // kind=4,8,10,16
+    return builder.createConvert(
+        loc, resultType,
+        fir::runtime::genScale(builder, loc, args[0], args[1]));
 
-  mlir::Value realX = fir::getBase(args[0]);
-  mlir::Value intI = fir::getBase(args[1]);
-
-  return builder.createConvert(
-      loc, resultType, fir::runtime::genScale(builder, loc, realX, intI));
+  // Convert kind=2,3 arg X to kind=4. Convert kind=4 result back to kind=2,3.
+  mlir::Type i1Ty = builder.getI1Type();
+  mlir::Type f32Ty = mlir::Float32Type::get(builder.getContext());
+  mlir::Value result = builder.createConvert(
+      loc, resultType,
+      fir::runtime::genScale(
+          builder, loc, builder.createConvert(loc, f32Ty, args[0]), args[1]));
+
+  // kind=4 runtime::genScale call may not signal kind=2,3 exceptions.
----------------
vdonaldson wrote:

It would be reasonable to make this distinction, and some compilers do have differences for `SCALE` vs. `IEEE_SCALB`. However, the front end replaces calls to `IEEE_SCALB` with calls to `SCALE`, which means there is currently no distinction in lowering for any kind, including kinds 2,3.

We do have the option of dropping exception generation just for kinds 2,3 (for both `SCALE` and `IEEE_SCALB`), since the relative cost compared to other kinds is not equal. However, 1) that would be a change vs. other kinds; and 2) we have tests that exercise this code that look for exceptions for `IEEE_SCALB`.

The net result of this is that my preference is to retain consistency within our implementation versus other kinds at least for now. These choices could be revisited for all kinds in the future, including de-aliasing the two calls.

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