[all-commits] [llvm/llvm-project] 06c51b: [IR] Allow non-constrained math intrinsics in stri...

[Serge Pavlov via All-commits]

  Branch: refs/heads/users/spavloff/bundles.no
  Home:   https://github.com/llvm/llvm-project
  Commit: 06c51b1a110d653a2474780d0dd70d162b09781f
      https://github.com/llvm/llvm-project/commit/06c51b1a110d653a2474780d0dd70d162b09781f
  Author: Serge Pavlov <sepavloff at gmail.com>
  Date:   2026-03-25 (Wed, 25 Mar 2026)

  Changed paths:
    M clang/test/CodeGen/strictfp-elementwise-builtins.cpp
    M llvm/docs/LangRef.rst
    M llvm/docs/ReleaseNotes.md
    A llvm/include/llvm/IR/FloatingPointOps.def
    M llvm/include/llvm/IR/Function.h
    M llvm/include/llvm/IR/IRBuilder.h
    M llvm/include/llvm/IR/InstrTypes.h
    M llvm/include/llvm/IR/Intrinsics.h
    M llvm/include/llvm/Support/ModRef.h
    M llvm/lib/Analysis/BasicAliasAnalysis.cpp
    M llvm/lib/Analysis/GlobalsModRef.cpp
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h
    M llvm/lib/IR/Function.cpp
    M llvm/lib/IR/IRBuilder.cpp
    M llvm/lib/IR/Instructions.cpp
    M llvm/lib/IR/Intrinsics.cpp
    M llvm/test/CodeGen/AMDGPU/amdgpu-simplify-libcall-pow.ll
    M llvm/test/CodeGen/AMDGPU/amdgpu-simplify-libcall-pown.ll
    M llvm/test/CodeGen/AMDGPU/amdgpu-simplify-libcall-rootn.ll

  Log Message:
  -----------
  [IR] Allow non-constrained math intrinsics in strictfp functions

The current implementation of floating-point support uses two different
representations for each floating-point operation, such as `llvm.trunc`
and `llvm.experimental.constrained.trunc`. The main difference between
them is the presence of side effects that describe interaction with the
floating-point environment. Which of the two functions should be used is
determined by the enclosing function's attribute 'strictfp'. The
compiler does not check whether a regular functions, like `llvm.trunc`
is used in a strictfp function, so maintaining consistency is the user's
responsibility.  It is easy to mistakenly use the regular,
side-effect-free intrinsic in a strictfp function, and even LLVM tests
contain examples of this.

If the variant of intrinsic is determined solely by the 'strictfp'
function attribute, the distinction between the two forms appear to be
redundant, and the regular form could be used in all cases. This would
require the compiler to deduce side effects from the function
attributes. In this scenario, floating-point operations would have
"optional" side effects.

Currently, it is not possible to completely avoid constrained functions.
In addition to representing side effects, they can also carry compiler
hints, namely the expected rounding mode and exception behavior.
However, using regular intrinsics in a strictfp function could be
allowed if the mechanism of optional side effects were implemented for
them. Such a change would make the current implementation of strictfp
support more robust and would represent a step toward more powerful
floating-point support.

This change implements minimal support for optional side effects in
floating-point operations sufficient to allow use of non-constrained
math function intrinsics in strictfp code. It does not alter the
compiler's behavior for the code that is correct under the current
floating-point model, it affects only the case of non-constrained
intrinsics used in a strictfp function, which is currently disallowed.



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