[qt/clang/llvm-project]: Summary of bulk changes made

Git repository change summary for qt/clang/llvm-project
Pushed by mirror-service into branch 'upstream/users/spavloff/bundles.no'.
Changed from 8a249021eaea0379ee4b7af0965df9ff837a85e2 to 3e84673291b3d313674fb3e8172b0a858c0409bb
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit d6b94ff53b16cf7959ad0fc2a39ed5c051c11f23 by Serge Pavlov on 03/08/2026 at 07:08..
[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.
https://invent.kde.org/qt/clang/llvm-project/-/commit/d6b94ff53b16cf7959ad0fc2a39ed5c051c11f23

Git commit 4e798481ca9fede0b7a73237def9342e9be20aec by Serge Pavlov on 03/08/2026 at 07:08..
Update the patch according to feedback:

- Remove the changes from IRBuilder, CallBase::getMemoryEffects() must be
  enough.
- Update documentation, remove extra terms, fix wording.
- Add tests that check correct ordering.
- Update macro names in FloatingPointOps.def.
- If an instruction is isolated, it is considered strictfp.
https://invent.kde.org/qt/clang/llvm-project/-/commit/4e798481ca9fede0b7a73237def9342e9be20aec

Git commit 3e84673291b3d313674fb3e8172b0a858c0409bb by Serge Pavlov on 03/08/2026 at 07:08..
Fix LLVM_ABI decoration
https://invent.kde.org/qt/clang/llvm-project/-/commit/3e84673291b3d313674fb3e8172b0a858c0409bb