[all-commits] [llvm/llvm-project] 3ad43f: [LangRef] Clarify nsz semantics (#180906)

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3ad43f2d1c03f7f04bd2943e9411a7986b1962c3
      https://github.com/llvm/llvm-project/commit/3ad43f2d1c03f7f04bd2943e9411a7986b1962c3
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2026-03-02 (Mon, 02 Mar 2026)

  Changed paths:
    M llvm/docs/LangRef.rst
    M llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
    M llvm/test/Transforms/InstCombine/intrinsic-select.ll

  Log Message:
  -----------
  [LangRef] Clarify nsz semantics (#180906)

The current LangRef wording says that the sign of a zero argument or
result is "insignificant", which is not really clear on what this means.

Alive2 models this as non-deterministically flipping the zero sign bits
for both inputs and outputs.

This PR proposes to specify this flag as non-deterministically flipping
inputs only. A consequence of this is that fabs is guaranteed to have an
unset sign bit even if the input is zero (that is,
https://alive2.llvm.org/ce/z/irCftQ is no longer a valid transform), and
that the copysign result sign only depends on the second operand (that
is, https://alive2.llvm.org/ce/z/VnHdfh is no longer a valid transform).

These rules are still more liberal than we'd really like them to be, but
at least avoid some of the issues with nsz.

This is based on the discussion in:
https://discourse.llvm.org/t/rfc-clarify-the-behavior-of-fp-operations-on-bit-strings-with-nsz-flag/85981



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications