[Bug target/105246] New: [amdgcn] Use library call for SQRT with -ffast-math + provide additional option to use single-precsion opcode

[Bug target/105246] New: [amdgcn] Use library call for SQRT with -ffast-math + provide additional option to use single-precsion opcode

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105246

            Bug ID: 105246
           Summary: [amdgcn] Use library call for SQRT with -ffast-math +
                    provide additional option to use single-precsion
                    opcode
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: documentation, wrong-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: ams at gcc dot gnu.org
  Target Milestone: ---
            Target: amdgcn-amdhsa

AMD GCN hardware has opcodes which operate on double-precision variables as
input/output but internally only do single-precision operation.

This affects (currently) only "sqrt" which for -funsafe-math-optimizations
(implied by -Ofast / -ffast-math) uses AMDGCN's "v_sqrt".

Namely gcc/config/gcn/gcn-valu.md has:

(define_insn "sqrt<mode>2<exec>"
...
  "flag_unsafe_math_optimizations"
  "v_sqrt%i0\t%0, %1"


Thus: while "v_sqrt" works on double-precision variables, it only calculates
with 23bits (as with float32) instead of 52bits (as float64 provides) for the
fractional part of the floating-point number.


PROBLEM: In many cases, this loss of precision by an order of 100,000,000 (10⁸
/ 2²⁹) is
very unexpected and too much for code which requires double precision. An ULP
of 4 is
expected not an ULP of 10⁸!

In particular: In order to permit several optimizations, -Ofast or --fast-math
is
commonly recommended and the precision loss is unexpected.

In terms of testsuites, OvO's sqrt examples are effected, requiring a way
higher
OVO_TOL_ULP to pass (→ https://github.com/TApplencourt/OvO )
But the issue really came up when discussion with HPC code users.

EXPECTED:
- By default, with -ffast-math, do the double-precision operation by a library
call
- Provide some (GCN-specific) -m... flag to do those calculations in single
precision.

For instance something like:

 -mpermit-reduced-precision
     Use hardware intrinsics instead of library even if they provide a much
     reduced precision. Example: use v_sqrt with double-precision variables
     even though the hardware only provides single-precision results for the
     fractional part of the floating-point variable. (Default: disabled)

[Bug target/105246] [amdgcn] Use library call for SQRT with -ffast-math + provide additional option to use single-precsion opcode

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105246

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
can one improve the precision by employing some additional NR step or so, using
v_sqrt only for the initial guess?  I agree that just v_sqrt isn't good for
-funsafe-math-optimizations.

[Bug target/105246] [amdgcn] Use library call for SQRT with -ffast-math + provide additional option to use single-precsion opcode

[ams at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105246

--- Comment #2 from Andrew Stubbs <ams at gcc dot gnu.org> ---
When we first coded this we only had the GCN3 ISA manual, which says nothing
about the accuracy.

Now I look in the Vega manual (GCN5) I see:

  Square root with perhaps not the accuracy you were hoping for --
  (2**29)ULP accuracy. On the upside, denormals are supported.

The most recent CDNA2 manual is a bit less verbose:

  Square root. Precision is (2**29) ULP, and supports denormals.

The compiler already emits Newton Raphson iterations for division with
-ffast-math, so I'm sure it can be done, but I'm not too clear on the
mathematics myself.