[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/main'.
Changed from 4e924a6276ef015e1482b68371bb8229368fe5f7 to 6be9888a7bb5995169e31ab03939f1ac03059b7a
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 b1e21e2e31541b02ea15719d6b7eec6bbb5508c1 by GitHub (on behalf of Florian Hahn) on 02/08/2026 at 11:34..
[VPlan] Handle step where sign cannot be determined optimizeFindIVRed. (#213450)

optimizeFindIVReductions uses the step to determine if min or max is
needed. Bail out if the direction of the step cannot be determined via
SCEV.

Fixes https://github.com/llvm/llvm-project/issues/213424
https://invent.kde.org/qt/clang/llvm-project/-/commit/b1e21e2e31541b02ea15719d6b7eec6bbb5508c1

Git commit 29a956e40a1f617887ecfeb02ae844102c4a5a48 by GitHub (on behalf of Robert Imschweiler) on 02/08/2026 at 12:01..
[offload][OpenMP] Add atomic cross-team reductions (#209298)

Regular cross-team reductions have two phases: the intra-team reduction
and the inter-team reduction. Atomic cross-team reductions replace the
second phase with a atomic instruction which is used by the main thread
of each team to directly fold the result of the intra-team reduction
into the final result. Since this requires a combination of "data type"
and "combine operation" for which an atomic instruction is available,
only some (but very common) reductions can be transformed to atomic
reductions. In cases where multiple reductions are performed on the same
construct, the atomic path is only taken if all reductions can be
transformed. Otherwise, we fall back to the regular cross-team reduction
using a buffer with per-team slots. This is not strictly necessary, but
hybrid reductions would induce more complexity with questionable
benefit.

Selecting an atomic path might not be the best option for every
situation, which is why it is not enabled by default. Instead, it can be
enabled via `-fopenmp-target-atomic-reduction`. Note that enabling the
atomic path will not *force* atomic reductions. They will only be
applied if possible, as described above.

The performance (measured with https://github.com/ro-i/xteam-test @
c71339705091500f731e2a39f247d2660bacbdce, array size 177,777,777) is up
to +15% faster (aka, more throughput) for supported reductions on a
gfx942, with no noticeable regressions.
Example:
- sum reduction, type double: +10.22% faster
- sum reduction, type uint: +15.57% faster
- sum reduction, type ulong: +13.31% faster

On a gfx90a, there is little to negative benefit:
- sum reduction, type double: -4.32% faster (aka, slower)
- sum reduction, type uint: +3.08% faster
- sum reduction, type ulong: +1.68% faster

Claude assisted with this patch.
https://invent.kde.org/qt/clang/llvm-project/-/commit/29a956e40a1f617887ecfeb02ae844102c4a5a48

Git commit 4695d911c68df381d3a1b088570bca8bc0c6bf23 by GitHub (on behalf of Lang Hames) on 02/08/2026 at 12:08..
[ORC] Generalize RTBridge Callers to any runtime function (#213526)

An RTBridge Caller is a controller-side handle for calling a function in
the runtime. Until now the abstraction assumed every such function was a
trampoline -- a runtime function whose job is to invoke *another*
function at an address the controller supplies (run-as-main, run-as-int,
etc.) -- so every Caller carried a dedicated ExecutorAddr parameter for
that target.

Generalize Callers to call runtime functions of any shape. Invoking a
supplied target is now just one kind of call, with the target address an
ordinary leading argument rather than a built-in parameter: e.g.
MainCaller becomes Caller<int64_t(ExecutorAddr, ArrayRef<std::string>)>.

The SPS signatures already led with an SPSExecutorAddr for the target,
so this is a pure interface change -- the SPS wrappers and all call
sites are unaffected. It lets Callers model runtime functions that do
the work themselves, such as the memory-access wrappers, rather than
only those that dispatch to another function.
https://invent.kde.org/qt/clang/llvm-project/-/commit/4695d911c68df381d3a1b088570bca8bc0c6bf23

Git commit 9a19c7750f949c979372ba1d2eec8a7a40061aef by GitHub (on behalf of Rainer Orth) on 02/08/2026 at 12:22..
[clang][Driver] Fix libc++ include path on NetBSD (#212716)

`clang++` defaults to `-stdlib=libc++` on NetBSD. When building with
both `clang` and `libcxx` included, the freshly built `clang++` fails to
find `<__config_site>`:

```
In file included from /usr/include/strings.h:68:
In file included from bin/../include/c++/v1/string.h:57:
bin/../include/c++/v1/__config:13:10: fatal
error: '__config_site' file not found
   13 | #include <__config_site>
      |          ^~~~~~~~~~~~~~~
```

The file is present in `include/<triplet>/c++/v1`, but that isn't
searched by default. NetBSD has its own version of addLibCxxIncludePaths
which misses that directory.

This patch removes `NetBSD::addLibCxxIncludePaths` in favour of the
generic version in `Gnu.cpp`. The current code also adds
`/usr/include/c++`, although this directory only contains empty
directories in a default installation. It is only used when a bundled
version of LLVM is installed, which is not usually the case, and even
then contains a static version of `__config_site` that only applies to
`libcxxrt`.

Tested on `amd64-pc-netbsd10.1`, `x86_64-pc-solaris2.11`,
`x86_64-pc-linux-gnu`, and `x86_64-pc-freebsd15.1`.
https://invent.kde.org/qt/clang/llvm-project/-/commit/9a19c7750f949c979372ba1d2eec8a7a40061aef

Git commit eee7c2d224d810f7da1b4a6fa462e5c14ef02365 by GitHub (on behalf of mkovacevic99) on 02/08/2026 at 12:39..
[ORC] Add AutoImportGenerator for COFF dllimport auto-import (#203914)

On Windows/COFF, a dllimport call is emitted as an indirect call through
an `__imp_` IAT slot (`callq *__imp_bar(%rip)`), and even a direct call
to a library function is expected to bind to a thunk supplied by an
import library. Today a JIT client must produce those import libraries
themselves. `AutoImportGenerator` synthesizes them on demand instead.

Bound to a single dynamic library via `AutoImportGenerator::Load(ES,
ObjLinkingLayer, "/path/to/lib.dll")`.
For each referenced export `X`, lazily synthesizes an `__imp_X` pointer
slot holding `X`'s address in the library plus an `X` thunk that jumps
through it, so both `__imp_`-mediated and direct references resolve.


The library's export table is the authority: a name the library does not
export is left unresolved, so the link fails exactly as a static link
against the corresponding import library would (no silent invention of
symbols).
All synthesized stubs are owned by a single `ResourceTracker`
(`getImportStubsResourceTracker()`), so a client can reclaim every
synthesized slot/thunk in one step; subsequent imports start a fresh
tracker.

Relationship to `DLLImportDefinitionGenerator`: that generator resolves
the underlying symbol through the JITDylib's link order.
`AutoImportGenerator` is bound to one specific library and treats its
export table as authoritative, giving fail-as-static-linker semantics.

x86_64 and in-process execution only. - "Easy mode": every import is
assumed to be a function; code and data are not distinguished, so data
imports are unsupported (clients with data imports must supply an import
library or use `__declspec(dllimport)`). `&X` resolves to the
synthesized thunk, not the implementation in the target library.
`llvm-jitlink -auto-import=<lib>` flag to attach the generator
(in-process; errors if combined with out-of-process execution).
Documentation in `llvm/docs/ORCv2.rst`.

Partly implements github issue:
https://github.com/llvm/llvm-project/issues/190122
In the comment section of the github issue there is this comment
https://github.com/llvm/llvm-project/issues/190122#issuecomment-4617328036
This PR implements point 3 ("Easy mode" generator)
https://invent.kde.org/qt/clang/llvm-project/-/commit/eee7c2d224d810f7da1b4a6fa462e5c14ef02365

Git commit 2a4acc46ea711175ef5cfe6ea5a795f62221084a by GitHub (on behalf of Alexey Bataev) on 02/08/2026 at 12:46..
[SLP][NFC]Add extra test for alt opcodes vectorization with copyables, NFC



Reviewers: 

Pull Request: https://github.com/llvm/llvm-project/pull/213538
https://invent.kde.org/qt/clang/llvm-project/-/commit/2a4acc46ea711175ef5cfe6ea5a795f62221084a

Git commit 036af906f355771a5c2b3bb51a88d995c6010219 by GitHub (on behalf of Brian Cain) on 02/08/2026 at 13:05..
[Hexagon] Avoid predicating debug instructions (#212917)

The change is made in HexagonExpandCondsets::(predicate) function. The
debug instructions are not predicable as they cannot be separated into
conditional branches. So while predicating instructions in a machine
basic block if we encounter any debug instructions we need to skip these
instructions and continue with other instructions.

The scan that collects the registers defined and used between the
definition of the source register and the conditional transfer bailed
out as soon as it saw a non-virtual register operand, which a DBG_VALUE
can have. The transfer was then left as an unconditional A2_asrh plus an
A2_tfrf instead of being folded into a single predicated A4_pasrhf, so
again the generated code differed depending on whether debug info was
enabled.

Co-authored-by: Chandana Sinderikeri <[email protected]>
https://invent.kde.org/qt/clang/llvm-project/-/commit/036af906f355771a5c2b3bb51a88d995c6010219

Git commit 7ed5bbedff3fa9dae894c2d939c7936f7a51a91f by GitHub (on behalf of OHNope) on 02/08/2026 at 14:06..
[Clang][OpenMP] Skip Sema actions for invalid assumption clauses (#212822)

Do not call the Sema actions for absent, contains, and nullary assumption
clauses after the parser has diagnosed that the clause is not allowed on the
current directive.

Add assertions documenting that these Sema actions must only receive clauses
allowed on the current directive, and add tests covering all affected clause
kinds.

Fixes #212780.
https://invent.kde.org/qt/clang/llvm-project/-/commit/7ed5bbedff3fa9dae894c2d939c7936f7a51a91f

Git commit e4693c0579ed0f3df45a06b918d448795b738a58 by GitHub (on behalf of lntue) on 02/08/2026 at 15:13..
[libc] Add __isoc99_fscanf alias. (#213125)

- Add LLVM_LIBC_ADD_FUNCTION_C_ALIAS macro to add another C alias public
symbol to a function.
- Add LIBC_CONF_SCANF_PROVIDE_ISOC99_ALIASES config
- Add __isoc99_fscanf for generic fscanf target if
LIBC_CONF_SCANF_PROVIDE_ISOC99_ALIASES is set.
- Similarly: scanf, vfscanf, vscanf.
https://invent.kde.org/qt/clang/llvm-project/-/commit/e4693c0579ed0f3df45a06b918d448795b738a58

Git commit def770df8325fb60107c24a2de3068aa762754ab by GitHub (on behalf of Nerixyz) on 02/08/2026 at 15:53..
[lldb] Fix typo in SBUnixSignals.get_unix_signals_list (#213527)

Found when looking through the generated Python file. `sig` doesn't
exist in that context, it should be `idx`.
https://invent.kde.org/qt/clang/llvm-project/-/commit/def770df8325fb60107c24a2de3068aa762754ab

Git commit 84046ac88f3104def05049a701535a79c19560bd by GitHub (on behalf of Jonas Devlieghere) on 02/08/2026 at 16:37..
[lldb][test] Recognize a Wasm trap as a crash (#213551)

is_thread_crashed maps how each platform reports the bad access the test
suite uses to simulate a crash, and had no case for Wasm, where there
are no signals and a bad access raises a trap that a runtime reports as
an exception. Without one it fell through to a description match that
never held, so a crashed thread read as running fine.
https://invent.kde.org/qt/clang/llvm-project/-/commit/84046ac88f3104def05049a701535a79c19560bd

Git commit 6be9888a7bb5995169e31ab03939f1ac03059b7a by GitHub (on behalf of higher-performance) on 02/08/2026 at 17:09..
Speed up std::visit() compile times by another 42% (#213203)

This avoids defining an `enum`, which appears to be expensive for Clang.
https://invent.kde.org/qt/clang/llvm-project/-/commit/6be9888a7bb5995169e31ab03939f1ac03059b7a