[llvm-bugs] [Bug 43711] [AMDGPU] fneg optimized to xor with sign bit removed

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Oct 22 05:11:53 PDT 2019


https://bugs.llvm.org/show_bug.cgi?id=43711

Connor Abbott <cwabbott0 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |cwabbott0 at gmail.com
         Resolution|INVALID                     |---

--- Comment #3 from Connor Abbott <cwabbott0 at gmail.com> ---
nir_op_fneg in Mesa canonicalizes the result because that's what Vulkan
requires. Specifically VK_KHR_floating_point_controls requires that the SPIR-V
OpFNeg flushes denorms to 0 when flushing denorms is enabled for the shader.

We currently map nir_op_fneg to "fsub -0, x" using LLVMBuildFNeg(). This should
produce a canonical result, the same as if I say "fsub y, x" and y happens to
be -0, and be identical to a normal fneg otherwise except maybe with funky
rounding modes. In the past this was what Clang also did, even though C/C++'s
negate operator maps to the standard IEEE sign bit operation that you quoted,
so it was wrong, and only recently has there been a native FNeg instruction
added which does just sign bit fiddling (and I don't even know if Clang uses it
yet). Backends then detected "fsub -0, x" and turned it back into an xor
instruction, which fixes the original clang bug but introduces a new one for
things like "float x = -0, y = ...; return x - y;" This is still happening with
AMDGPU, and now that we're trying to support DX games where DX expects that you
consistently flush denorms when adding/subtracting, that's not great.

I'm not sure moving forward what the canonical way is for an LLVM frontend to
emit a negate that also canonicalizes, "fsub -0, x" or "canonicalize(fneg(x))".
But the current LLVM behavior where "fsub -0, x" gets remapped to "fneg(x)" is
definitely wrong.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191022/9a93747e/attachment.html>


More information about the llvm-bugs mailing list