[PATCH] D63061: [builtins] Fix overflow issue for complex division with big numbers

[Steve Canon via Phabricator via llvm-commits]

scanon added inline comments.


================
Comment at: lib/builtins/divdc3.c:33
   Dcomplex z;
-  COMPLEX_REAL(z) = crt_scalbn((__a * __c + __b * __d) / __denom, -__ilogbw);
-  COMPLEX_IMAGINARY(z) =
-      crt_scalbn((__b * __c - __a * __d) / __denom, -__ilogbw);
+  COMPLEX_REAL(z) = (__a * __c + __b * __d) / __denom;
+  COMPLEX_IMAGINARY(z) = (__b * __c - __a * __d) / __denom;
----------------
This rescaling strategy is still prone to overflow. Consider `a = b = DBL_MAX`, `c = d = 1`. The rescaled `a*c + b*d` will still overflow, because `max(c,d)` is 1, but the result should be finite.

In general, I don't think that you can implement a rescaled division like this without considering the scaling of both (a,b) and (c,d); it doesn't suffice to only use the scaling  of (c,d) alone.


================
Comment at: lib/builtins/divsc3.c:21
 COMPILER_RT_ABI Fcomplex __divsc3(float __a, float __b, float __c, float __d) {
   int __ilogbw = 0;
   float __logbw =
----------------
On targets where we have hardware double-precision, it would be a huge win for float to simply promote to double and skip rescaling entirely. We still need the inf/nan checks, but for finite results this always gives the right answer.

This can be a follow-on patch, however.


Repository:
  rCRT Compiler Runtime

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63061/new/

https://reviews.llvm.org/D63061