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

Git repository change summary for qt/clang/llvm
Pushed by mirror-service into branch 'upstream/users/bhandarkar-pranav/issue_203915_ph2_pr1'.
Changed from 0000000000000000000000000000000000000000 to 5bf5520cc2252f5e433b05044deb4b1ff031aaf6
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 c301b9901ae93fa91c9861ce13d508d53191a378 by GitHub (on behalf of Matthew Devereau) on 03/08/2026 at 11:13..
[AArch64][SVE] Fold nested boolean UMIN trees (#209234)

Fold redundant UMIN clamps in logical boolean reduction trees when all
operations use the same predicate.
https://invent.kde.org/qt/clang/llvm/-/commit/c301b9901ae93fa91c9861ce13d508d53191a378

Git commit 5ce177f6cd3672aae1791ba155b5438c9198a8ce by GitHub (on behalf of Harald-R) on 03/08/2026 at 11:16..
Fix llvm-mlir-use-after-erase findings (#210733)

Fix the following warnings identified by the `llvm-mlir-use-after-erase`
check from https://github.com/llvm/llvm-project/pull/210727:

```cpp
mlir/lib/Transforms/Utils/DialectConversion.cpp:2700:33: warning: operation 'op' is used after it was erased [llvm-mlir-use-after-erase]
 2700 |           curState, std::string(op->getName().getStringRef()) + " folder");
      |                                 ^
mlir/lib/Transforms/Utils/DialectConversion.cpp:2685:12: note: operation erased here
 2685 |   rewriter.replaceOp(op, replacementValues);
      |            ^
mlir/lib/Dialect/MemRef/Transforms/NormalizeMemRefs.cpp:440:29: warning: operation 'newOp' is used after it was erased [llvm-mlir-use-after-erase]
  440 |           Value newMemRef = newOp->getResult(resIndex);
      |                             ^
mlir/lib/Dialect/MemRef/Transforms/NormalizeMemRefs.cpp:459:20: note: operation erased here 
  459 |             newOp->erase();
      |                    ^
mlir/lib/Dialect/MemRef/Transforms/NormalizeMemRefs.cpp:440:29: note: the use happens in a later loop iteration than the erase
  440 |           Value newMemRef = newOp->getResult(resIndex);
      |                             ^
```

The warning at `NormalizeMemRefs.cpp:440` is resolved by breaking the
loop iteration after erasing the operation, similar to what is done at
line 306.
https://invent.kde.org/qt/clang/llvm/-/commit/5ce177f6cd3672aae1791ba155b5438c9198a8ce

Git commit 2ef2ab65e8622a81b060b96a2ed579816d01f03f by GitHub (on behalf of Kamlesh Kumar) on 03/08/2026 at 11:26..
[AArch64] Update tests with interleave intrinsics (#212312)
https://invent.kde.org/qt/clang/llvm/-/commit/2ef2ab65e8622a81b060b96a2ed579816d01f03f

Git commit d2b28a818981d9703f2ebf0eeeb5e1d9d77dec51 by GitHub (on behalf of Ramkumar Ramachandra) on 03/08/2026 at 11:37..
[ConstFold] Fold fixed-vectors in constantFoldIntrinsic (#213625)

This exposes an underlying bug in wasm.dot-folding, which we fix. The
motivation for this patch is to enable folding of get.active.lane.mask
in VPlan in a follow-up.
https://invent.kde.org/qt/clang/llvm/-/commit/d2b28a818981d9703f2ebf0eeeb5e1d9d77dec51

Git commit 3db0dd71c8579fb825bdd2c6148b53496e485375 by GitHub (on behalf of Manuel Carrasco) on 03/08/2026 at 11:44..
Implement support for NSDI DebugFunctionDefinition. (#211853)

This PR depends on the DebugFunction PR:
https://github.com/llvm/llvm-project/pull/211760. This PR implements
support for
[DebugFunctionDefinition](https://github.khronos.org/SPIRV-Registry/nonsemantic/NonSemantic.Shader.DebugInfo.html#DebugFunctionDefinition).

DebugFunctionDefinition must be emitted within the instruction sequence
of its corresponding OpFunction. The current implementation inserts
DebugFunctionDefinition immediately after the last OpVariable, if one
exists, or otherwise immediately after the first OpLabel. The goal is to
satisfy the following
[requirement](https://github.khronos.org/SPIRV-Registry/nonsemantic/NonSemantic.Shader.DebugInfo.html#_binary_form):

> DebugScope, DebugNoScope, DebugDeclare, DebugValue, DebugLine,
DebugNoLine, and DebugFunctionDefinition instructions may interleave
with instructions inside a function, but they must appear at valid
locations within a block as required by SPV_KHR_non_semantic_info. In
particular, they cannot appear before any OpPhi or function-level
variable declarations in a block, and they cannot appear after a merge
instruction.

To support this, I updated SPIRVAsmPrinter to notify the debug handler
whenever an instruction is emitted. The debug handler maintains a small
amount of state so it can detect when the last OpVariable or the first
OpLabel has been emitted and insert DebugFunctionDefinition at the
appropriate location.
https://invent.kde.org/qt/clang/llvm/-/commit/3db0dd71c8579fb825bdd2c6148b53496e485375

Git commit 6a7f6a02bb95a75c615cde3194ad77d776b869c5 by GitHub (on behalf of Benedek Kaibas) on 03/08/2026 at 11:50..
[analyzer] Implement BugReporterVisitor for UseAfterLifetimeEnd to trace lifetime source binding (#207052)

Currently the `UseAfterLifetimeEnd` checker can emit warnings, but those
warnings cannot clearly describe to which annotated parameter the return
value is actually bound. When multiple parameters are annotated, it is
unclear which one the return value is bound to. Using
`BugReporterVisitor` to trace back the nodes and emit a note that
explains where the lifetime of the annotated parameter (the source)
ended can be helpful for users.

***NOTE***: This PR is built on #205951. It should only be merged after
#205951 is merged.

Consider the following case: 

```cpp
#include <stddef.h>

class Arena {
  char buf[128];
  char *buffer = buf;
  size_t offset = 0;

public:
  void *allocate(size_t size) [[clang::lifetimebound]] {
    void *p = buffer + offset;
    offset += size;
    return p;
  }
  void reset() {offset = 0;}
};

void *arena_dangling() {
  Arena arena;
  void *p = arena.allocate(128);
  arena.reset();
  return p; // arena goes out of scope therefore p dangles
}
```

The `UseAfterLifetimeEnd` checker correctly detects this error and emits
path notes that trace where the value was bound and where its lifetime
ends:

```text
temp.cpp:21:3: warning: Returning value bound to 'arena' that will go out of scope [alpha.cplusplus.UseAfterLifetimeEnd]
   21 |   return p;
      |   ^~~~~~~~
temp.cpp:19:13: note: Value bound to 'arena' here
   19 |   void *p = arena.allocate(128);
      |             ^~~~~~~~~~~~~~~~~~~
temp.cpp:21:3: note: Lifetime of 'arena' ended here
   21 |   return p;
      |   ^~~~~~~~
1 warning generated.
```

The motivating example comes from here:
https://discourse.llvm.org/t/clang-static-analyzer-gsoc-2025-teach-the-clang-static-analyzer-to-understand-lifetime-annotations/84487/41?u=bkaibas01
https://invent.kde.org/qt/clang/llvm/-/commit/6a7f6a02bb95a75c615cde3194ad77d776b869c5

Git commit 68449895e267174801d3b11afd957548f5796a41 by GitHub (on behalf of Kacper Doga) on 03/08/2026 at 12:16..
[GlobalISel] emit G_BITCAST in widenScalarMergeValues when DstTy does not match WideTy (#203014)

**Problem:**
`LegalizerHelper::widenScalarMergeValues` does not handle the case where
the destination register type is a floating-point type but the widen
operation produces an integer type of the same size.

For example, given:
```
%0:_(i8) = G_CONSTANT i8 0
%1:_(i8) = G_CONSTANT i8 1
%2:_(f16) = G_MERGE_VALUES %0:_(i8), %1_:(i8)
```
With a `minScalarOrElt` rule widening the source type to I16,
`widenScalarMergeValues` enters the `WideSize >= DstSize` path and
assigns the result to a new virtual register. The condition used to
assign directly to DstReg uses type equality (WideTy == DstTy), which
fails when DstTy = f16. As a result, DstReg is left without a
definition.

**Fix:**
After the OR-reduction loop, add a check for the case where DstTy and
WideTy have equal sizes but different types, and emit a G_BITCAST.

**Testing:**
No currently upstream target exercises `G_MERGE_VALUES` with a
floating-point destination type through this widen path, as most targets
promote f16 to s16 before legalization. The fix is therefore covered by
a unit test in `LegalizerHelperTest.cpp`, modeled after the existing
`WidenScalarMergeValuesPointer` test, which directly invokes widenScalar
on a manually constructed `f16 = G_MERGE_VALUES i8, i8` instruction and
verifies that a `G_BITCAST` is emitted as the final instruction.
https://invent.kde.org/qt/clang/llvm/-/commit/68449895e267174801d3b11afd957548f5796a41

Git commit 7bf1ded0e061cc388a31f4293afd527f76810ffb by GitHub (on behalf of William Tran-Viet) on 03/08/2026 at 12:23..
[libc++] Clean up headers that relied on `<optional>`'s transitive includes (#213158)

Clear out the headers in <optional> that were left in to not break
other headers, and fix them also. Also fix tests.
https://invent.kde.org/qt/clang/llvm/-/commit/7bf1ded0e061cc388a31f4293afd527f76810ffb

Git commit 97fd08dbaf82b35ef860bca11bb047fd60f723d5 by GitHub (on behalf of Kacper Doga) on 03/08/2026 at 12:24..
[GlobalISel] avoid G_TRUNC with floating-point G_MERGE_VALUES source (#206733)

With extended LLT, scalar LLT carry an integer/float kind information.
The `G_TRUNC(G_MERGE_VALUES)` fold in
`LegalizationArtifactCombiner::tryCombineTrunc` truncated, copied or
rebuilt a merge directly from the merge's source register.

**Problem**
When those sources are floating-point this produces artifacts with float
source operand - e.g. `i1 = G_TRUNC f32` or a rebuilt `iN =
G_MERGE_VALUES f32, ...` which are bit level integer operations and must
not take a float operand.

**Fix**
Reinterpret a floating-point merge source to an integer of the same size
via `G_BITCAST` before truncating, copying or rebuilding the merge. So
the emitted artifacts stay on integer operands. Non-float sources and
non-extended-LLT builds are unaffected.
https://invent.kde.org/qt/clang/llvm/-/commit/97fd08dbaf82b35ef860bca11bb047fd60f723d5

Git commit f84bacf82a153a75dbf549d8c25d6e73673ea043 by GitHub (on behalf of David Spickett) on 03/08/2026 at 12:31..
[lldb] Introduce RegisterType base class for all register type classes (#196960)

This is refactoring to prepare for
https://github.com/llvm/llvm-project/issues/87471. Where we will be
adding support for describing registers as unions and vectors. See:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Target-Description-Format.html

A union is like a C union and references other types defined in the XML.
Just like a set of register flags might reference an enum for one of
those flags.

By introducing this base class I'm making the treatment of all these
different types generic. So that when encoding them as XML we can emit
the type's dependencies recursively, and then emit the type itself.

This strategy will also be used later in RegisterTypeBuilderClang to
generate AST to represent these types.

As GDB decided to include size in enums, whenever we emit something it
will get a "user" pointer. This allows an enum type to read the size of
the register it's being attached to. No other type class requires this.

I would call this "parent" but it is not usually the parent. The
heirarchy is:
* A RegisterFlags type contains many flags.
* One of those flags has an enum as its type.
* That enum needs to query two levels up to get the RegisterFlag's size.

LLDB does not care about this enum size attribute, but GDB does so we
emit it for compatibility.

I don't expect anything other than a RegisterFlags to reference an enum
at this time. In theory, a vector's element could be an enum but I do
not know of anything available today that does this.

I'd like to support arbitrary nesting of these types, but only later
once known use cases work well.

For the time being, the generic RegisterType pointer is cast into a
RegisterFlags before use. In future this will become a switch over the
possible register types we support.
https://invent.kde.org/qt/clang/llvm/-/commit/f84bacf82a153a75dbf549d8c25d6e73673ea043

Git commit fccabca20c732cc93b018effa7381e2e2a6f9506 by GitHub (on behalf of Timm Baeder) on 03/08/2026 at 12:46..
[clang][bytecode] Protect against invalid C++26 string repr (#213639)

We can't call `getNumElems()` for unknown-size arrays.
https://invent.kde.org/qt/clang/llvm/-/commit/fccabca20c732cc93b018effa7381e2e2a6f9506

Git commit ea2933f9aae9dc0bf4bb120bb732c0758d1026fd by GitHub (on behalf of Tom Eccles) on 03/08/2026 at 12:48..
[flang][Lower] Flatten signed real sum terms (#211829)

Second part of generalisations requested in #207377.

Extend real sum reassociation to flatten unparenthesized addition and
subtraction into signed terms. Rebuild split groups with addition and
subtraction while preserving parenthesized subtrees as opaque values.

I did not observe any benchmark result changes as a result of this
patch.

Assisted-by: Codex
https://invent.kde.org/qt/clang/llvm/-/commit/ea2933f9aae9dc0bf4bb120bb732c0758d1026fd

Git commit d2e2626045e2380e60f51e75c39acf245572c918 by GitHub (on behalf of Louis Dionne) on 03/08/2026 at 12:53..
[libc++] Don't rely on a transitively included BYTE_ORDER in ctype_base (#213032)

Use libc++'s own _LIBCPP_BIG_ENDIAN macro instead of BYTE_ORDER, which
was relied upon from a transitive <endian.h> include on Glibc.
https://invent.kde.org/qt/clang/llvm/-/commit/d2e2626045e2380e60f51e75c39acf245572c918

Git commit 3ea717b891a05dd00006b51e506b30198d57f763 by GitHub (on behalf of Louis Dionne) on 03/08/2026 at 12:54..
[libc++] Add missing includes in the locale headers (#213035)

Several headers use entities from `<__locale>` but rely on picking them
up transitively, in most cases through `<ios>`. Fix this in preparation
for splitting up `<__locale>`.
https://invent.kde.org/qt/clang/llvm/-/commit/3ea717b891a05dd00006b51e506b30198d57f763

Git commit dbd0c2d86f02528de4940ee87137259d9b7f0b85 by GitHub (on behalf of Nikolas Klauser) on 03/08/2026 at 12:55..
[libc++] Remove opt-out of the LLVM 23 transitive includes removal (#213245)

We've removed transitive includes by default in LLVM 23, but added an
opt-in to keep the transitive includes for the release. Now that we've
branched we can remove the transitive includes unconditionally.

RFC: https://discourse.llvm.org/t/rfc-remove-unused-transitive-includes-from-the-libc-headers
https://invent.kde.org/qt/clang/llvm/-/commit/dbd0c2d86f02528de4940ee87137259d9b7f0b85

Git commit 3d60487f83797a10a6379669647a139e6823d3d2 by GitHub (on behalf of Yair Ben Avraham) on 03/08/2026 at 12:58..
[CIR][AArch64] Lower remaining FP16 vfma and vfms builtins (#210359)

Complete CIR lowering coverage for the remaining AArch64 NEON FP16 fused
multiply-accumulate and fused multiply-subtract builtins.

This covers ACLE wrappers from section 2.6.1.9.3:
  - vfma_n_f16, vfmaq_n_f16
  - vfms_f16, vfmsq_f16
  - vfms_lane_f16, vfmsq_lane_f16
  - vfms_laneq_f16, vfmsq_laneq_f16
  - vfms_n_f16, vfmsq_n_f16
  - vfmsh_lane_f16, vfmsh_laneq_f16

The existing CIR lowering paths already handle these wrappers. Move
their tests from AArch64/v8.2a-neon-intrinsics.c into
AArch64/neon/fused-multiple-fullfp16.c, add direct LLVM, CIR-to-LLVM,
and CIR coverage, and remove the superseded tests.

Strengthen the LLVM checks by tracking operands from their defining
operations and using LLVM-DAG for order-independent setup operations.

Part of #185382
https://invent.kde.org/qt/clang/llvm/-/commit/3d60487f83797a10a6379669647a139e6823d3d2

Git commit 2a9aa12745874b5cff513f0d60a63845e6b783af by GitHub (on behalf of Walter Lee) on 03/08/2026 at 13:13..
Bazel 8d292a7c4b952eb5e9c55ed54a17a25c85bd553c (#213661)

This fixes
https://github.com/llvm/llvm-project/commit/8d292a7c4b952eb5e9c55ed54a17a25c85bd553c
(https://github.com/llvm/llvm-project/pull/213265).

Buildkite error link:
https://buildkite.com/llvm-project/upstream-bazel/builds?commit=8d292a7c4b952eb5e9c55ed54a17a25c85bd553c

Co-authored-by: Google Bazel Bot <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/2a9aa12745874b5cff513f0d60a63845e6b783af

Git commit 53ee7b167d8aee0a75c1332ca4a6aa037e0869a0 by GitHub (on behalf of Gábor Tóthvári) on 03/08/2026 at 13:13..
[NFC][analyzer] Eliminate NodeBuilder from ExprEngine visit methods and from their utility methods (#212186)

This patch eliminates the remaining uses of the class `NodeBuilder` from
the `ExprEngine::Visit*` methods and from their utility methods such as
`evalLocation`, `evalLoad`, `CreateCXXTemporaryObject` and
`handleConstructor`.
https://invent.kde.org/qt/clang/llvm/-/commit/53ee7b167d8aee0a75c1332ca4a6aa037e0869a0

Git commit 981286a235471cfffbf2b18201aea926a0803b9c by GitHub (on behalf of Nicole Aschenbrenner) on 03/08/2026 at 13:21..
[OpenMP] target-fast implies teams/threads oversubscription (#205775)

Enable -fopenmp-assume-teams-oversubscription and
-fopenmp-assume-threads-oversubscription by default under
-fopenmp-target-fast. Adds driver test coverage for both.

Split out of #205325 as a standalone change.
https://invent.kde.org/qt/clang/llvm/-/commit/981286a235471cfffbf2b18201aea926a0803b9c

Git commit 23f0aa2f2ea35a8e9b106f97d561482cbf6f17b5 by GitHub (on behalf of Simon Pilgrim) on 03/08/2026 at 13:26..
[X86] movmsk-cmp.ll - update PR39665_c_ray test to match middle-end output (#213659)

These now lower to vXi1 reduction (as bitcast) patterns

The PR39665_c_ray_opt test folds to the same IR, so I've merged the
tests
https://invent.kde.org/qt/clang/llvm/-/commit/23f0aa2f2ea35a8e9b106f97d561482cbf6f17b5

Git commit 587ddb34f741ffb8fbcbc258fcfea373463f392f by GitHub (on behalf of Arseniy Obolenskiy) on 03/08/2026 at 13:26..
[SPIR-V] Parse parameterized Memory Access operands with a shared helper (#209262)

Copy printing only special cased Aligned, so alias list and scope IDs
were then misread as additional masks
https://invent.kde.org/qt/clang/llvm/-/commit/587ddb34f741ffb8fbcbc258fcfea373463f392f

Git commit 49ace5ab8f1846b47fdad85ac698982e9cb8cda9 by GitHub (on behalf of Ashutosh Nema) on 03/08/2026 at 13:29..
[Transforms][Utils] Test for branch weight preservation in LoopSplitUtils (#213647)

Added a lit test test for branch weight
https://invent.kde.org/qt/clang/llvm/-/commit/49ace5ab8f1846b47fdad85ac698982e9cb8cda9

Git commit e78503c4f017a807c23e583f8a6e3ab94d712632 by GitHub (on behalf of Arseniy Obolenskiy) on 03/08/2026 at 13:29..
[SPIR-V] Fix validation errors for function pointers with CodeSectionINTEL storage class (#192973)

CodeSectionINTEL pointers are not valid operands for
PtrCastToGeneric/GenericCastToPtr (including inside OpSpecConstantOp)
https://invent.kde.org/qt/clang/llvm/-/commit/e78503c4f017a807c23e583f8a6e3ab94d712632

Git commit fc381d5bf9de78cb6b477f58cf58b8b52bad55de by GitHub (on behalf of Kyungtak Woo) on 03/08/2026 at 13:37..
[bazel] Export TripleName.def and get_triple_system_name.py in LLVM overlay (#213602)

The TargetParser lit regression test
(`llvm/test/tools/TargetParser/get-triple-system-name.test`) runs
`get_triple_system_name_test.py`, which imports
`get_triple_system_name.py` from `llvm/utils/` and reads
`TripleName.def` from `llvm/include/llvm/TargetParser/`.

When executing lit regression tests in downstream sandboxed build
systems, the test fails with `ModuleNotFoundError: No module named
'get_triple_system_name'` because these standalone files are located
outside the test directory and are not staged into the test runfiles
sandbox.

Add `TripleName.def` and `get_triple_system_name.py` to `exports_files`
in the overlay so downstream builds can reference them as test runfile
dependencies.

Assited by: Gemini
https://invent.kde.org/qt/clang/llvm/-/commit/fc381d5bf9de78cb6b477f58cf58b8b52bad55de

Git commit d2fcb0c9e11f8d8bedc45db0aeba9e0a53141fe5 by GitHub (on behalf of Timm Baeder) on 03/08/2026 at 13:47..
[clang][bytecode] Handle multiple base paths in dynamic_cast (#213592)

This can happen via virtual bases.

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

Git commit c4203d7b42554379f048e21124757498a67434a9 by GitHub (on behalf of Simon Pilgrim) on 03/08/2026 at 14:10..
[X86] movmsk-cmp.ll - update PR67287 test to match middle-end reduction output (#213671)

This now lowers to a vXi1 reduction (as bitcast) pattern
https://invent.kde.org/qt/clang/llvm/-/commit/c4203d7b42554379f048e21124757498a67434a9

Git commit 4905109b00e6916a310cf7c521bd8df19c0d4a11 by GitHub (on behalf of Spencer Bryngelson) on 03/08/2026 at 14:21..
[OpenMP] Analyze the loop-body callback of the static-loop runtime entries (#211287)

Fixes #211132. Also removes the trigger for #198621, see below.

`AAKernelInfo` treats the loop body passed to the
`__kmpc_*_static_loop_*` entries as opaque and records an unknown
parallel region for it, per the TODO at the site. Consequently
`NestedParallelism` is true for any kernel whose parallel region
contains a device workshare loop, and `MayUseNestedParallelism` is
written to the kernel environment as 1 where it should be 0.

The callback is a direct function operand at the callsite, so resolve it
and consult its `AAKernelInfo`, exactly as the `__kmpc_parallel_60`
handling already does for its parallel-region operand a few lines away.
Only record an unknown region when it does not resolve, or does reach
parallel regions. The SPMD-izability half of the TODO is left alone.

Only flang lowers device workshare loops through these entries; clang
emits `__kmpc_for_static_init_4` plus an explicit loop, which the
preceding case already handles. So flang kernels get 1 and clang kernels
get 0 on identical source. Controlled pair, flang, gfx90a:

| construct | runtime loop entry | before | after |
|---|---|---|---|
| `!$omp target parallel` | none | 0 | 0 |
| `!$omp target parallel do` | `__kmpc_for_static_loop_4u` | 1 | **0** |

What the 1 costs. It stops `config::mayUseNestedParallelism()` folding,
so the serialized branch in `__kmpc_parallel_60` stays live and carries
its own call to the microtask. After `__kmpc_parallel_60` is inlined
into the kernel there are then two calls to the outlined region rather
than one, `isSoleCallToLocalFunction` is false, and
`LastCallToStaticBonus` never applies. On AMDGPU that is 15000 x 11 =
165000; the analysis starts at -165045 with one callsite and -45 with
two. With two the region stays out of line and the kernel is no longer a
leaf.

`-Rpass-analysis=kernel-resource-usage`, VGPRs / scratch / occupancy:

| | before | after |
|---|---|---|
| reproducer from #211132, gfx90a | 212 / 48 B / 2 | **94 / 0 / 5** |
| WENO5 + HLLC NEQ=8, gfx942 | 196 / 64 B / 2 | **110 / 0 / 4** |
| NEQ=16 | 214 / 328 B / 2 | **138 / 0 / 3** |
| NEQ=24 | 196 / 456 B / 2 | **110 / 392 B / 4** |

End-to-end on gfx942 (MI325X), 1M cells, best of 50, Mcell/s, checksums
bit-identical: 1.35x, 1.47x, 1.28x at NEQ=8/16/24. Baseline run-to-run
spread across jobs is wider than the patched one, so treat the resource
numbers above, which are deterministic, as the primary evidence.

For #198621: step 2 of that root cause identifies the same
`MayUseNestedParallelism=1` as what prevents LTO folding
`omp_get_num_threads()` into a register read, which is what leaves
`DistributeFor` with `NumThreads=1` and skips a suffix of iterations.
Scalar kernels are immune there because they get 0. This refines the
field for the array-expression kernels too, so it addresses that cause
rather than the symptom.

Testing: added `spmdization_kernel_env_static_loop.ll`, which covers
both directions, a callback with no parallel region refining to 0 and a
callback that does contain one staying at 1. It fails without the patch.
`llvm/test/Transforms` (11676) and `llvm/test/CodeGen/AMDGPU` (4920),
16596 tests, 14668 passed with 39 expected failures and no regression.
The one failure, `Transforms/ThinLTOBitcodeWriter/no-type-md.ll`, is
pre-existing and fails identically with the patch reverted.

This affects performance-critical applications on large AMD GPU
supercomputers, including [MFC](https://github.com/MFlowCode/MFC).

All numbers above come from the validated reproducers attached to
#211132 and are independently reproducible; they stand on their own.

This was found and root-caused with the assistance of AI tools.
https://invent.kde.org/qt/clang/llvm/-/commit/4905109b00e6916a310cf7c521bd8df19c0d4a11

Git commit f7075d0da225b3de1cc83345a3a74d2f310d1057 by GitHub (on behalf of Jan Trusiłło) on 03/08/2026 at 14:40..
[offload] add nodiscard support to offload-tblgen and mark ol_errc_t (#209727)

Offload API functions may fail with error codes that shouldn't be
ignored. Most notably, if `olInit` fails and its error return value is
ignored, it is easy to use the library in an invalid uninitialized
state, which can and has caused confusion. In those cases, it may be
useful to have the ability to mark some API function with
`[[nodiscard]]`

This PR adds an optional `nodiscard` property to offload-tblgen's
`Function`, `Enum`, and `Struct`. If set, an `OL_NODISCARD` macro is
emitted, which expands to `[[nodiscard]]` on >=C++17 and >=C23, and to
nothing otherwise.

`nodiscard` is set for `ol_errc_t`, meaning every call to a function
that returns it will emit a compiler warning if the return value is
ignored and the TU is compiled on a supported language mode.

`libsycl` and `llvm-gpu-loader` still build cleanly and are unaffected
by the change.

Worth considering: should there be an opt-out (`#define
OL_DISABLE_NODISCARD` or similar)?

Assisted-by: Claude
https://invent.kde.org/qt/clang/llvm/-/commit/f7075d0da225b3de1cc83345a3a74d2f310d1057

Git commit deecdb92e1600c47b0dad4a13730440c7dbe7c17 by GitHub (on behalf of Alexey Bataev) on 03/08/2026 at 14:51..
[SLP][NFC]Add extra test with alternate add/sub vectorization, NFC



Reviewers: 

Pull Request: https://github.com/llvm/llvm-project/pull/213693
https://invent.kde.org/qt/clang/llvm/-/commit/deecdb92e1600c47b0dad4a13730440c7dbe7c17

Git commit 58f386207ac8dca5ad4729a3ba9e6f448fba99c3 by GitHub (on behalf of Ivan R. Ivanov) on 03/08/2026 at 14:55..
[offload] Remove `omptarget` references from tests (#208205)

Make check lines more generic so that we can move and rename components
without breaking the tests

This is in preparation for splitting off parts of libomptarget into
libompaccsupport, which will be used by both OpenACC and OpenMP. Some
debug prints will be printed from `ompaccsupport` and not `omptarget`,
thus the need for this change.
https://invent.kde.org/qt/clang/llvm/-/commit/58f386207ac8dca5ad4729a3ba9e6f448fba99c3

Git commit 22e413e73b4466cec6c20ea8bf5533e1370fd978 by Pranav Bhandarkar on 03/08/2026 at 15:42..
[flang-rt] - Lightweight runtime assignment function (AssignSimple) for intrinsic-type assignments.

This PR introduces a lightweight assignment runtime path (`_FortranAAssignSimple`) for intrinsic-type arrays
with the goal of reducing compile-time overhead seen primarily in the form of severly increased time taken by LTO.
This PR includes only the changes to the runtime (flang-rt) and as such just with this PR compile-time improvements
will not be visible.

**Problem**

When compiling Fortran code with OpenMP GPU offload and `firstprivate(allocatable_array)`, LLVM's Attributor creates excessive abstract attributes analyzing complex runtime assignment machinery:

**Symptom:**
- **Test case:** 8-element allocatable integer array with `firstprivate` clause
- **Compile time:** 24.97s (vs 0.78s for `private` - **32x slower**)
- **Root cause:** LLVM Attributor analyzing complex Fortran runtime functions

**Why this happens:**

1. `firstprivate` requires copying arrays from host to device
2. Flang generates call to `_FortranAAssign(to_device, from_host)`
3. LTO pulls in 177 runtime functions from `libflang_rt.runtime.a`
4. OpenMPOpt/Attributor analyzes all 177 functions, creating **1,041,950 abstract attributes**
5. Time spent in OpenMPOpt: **9.75s (39% of total compile time)**

**The core issue:** `_FortranAAssign` handles ALL Fortran assignment cases (scalar, array, polymorphic, character, derived type, user-defined assignment, aliasing detection, finalization) with **999 basic blocks** in a single function. For a trivial integer array copy, this forces the optimizer to analyze machinery it will never execute.

From Attributor debug output:
```
[Attributor] Update: [AAIsDead] for ... at position {fn:_FortranAAssign}
with state Live[#BB 1/999][#TBEP 1][#KDE 0]
                    ^^^
        999 basic blocks in ONE function!
```

**Overhead:**
- **Actually executed at runtime:** ~5-10 functions, ~200 basic blocks
- **Analyzed at compile-time:** 177 functions, ~1800 basic blocks
- **Overhead:** **17x-35x more code analyzed than executed**

Intrinsic types never have dynamic components requiring deferred operations, so the `WorkQueue` in `_FortranAAssign` is not really needed.
Therefore, we split the Fortran assignment runtime API based on statically known information:

**1. `_FortranAAssignSimple` (NEW) - Fast Path**
- Handles intrinsic type arrays (integer, real, complex, logical)
- Single `memmove()` for contiguous, element-wise loop for non-contiguous
- Minimal LTO pull-in (~3-4 functions vs 177)
- Runtime checks verify correct usage

**2. `_FortranAAssign` (EXISTING) - Complex Path**
- Handles derived types, polymorphic, character, user-defined assignment
- Retains full WorkQueue, finalization, aliasing detection machinery
- Only called when actually needed

`_FortranAAssignSimple` is used when ALL conditions are true:
1. Intrinsic element type (not derived type)
2. Matching ranks (no scalar-to-array broadcasting)
3. Non-volatile
4. Not polymorphic
5. Not explicit-length character
6. Not temporary LHS

This is a part of the fix for https://github.com/llvm/llvm-project/issues/203915
https://invent.kde.org/qt/clang/llvm/-/commit/22e413e73b4466cec6c20ea8bf5533e1370fd978

Git commit 50f1e37ff04df1e02d4f0cbb0faf5831bb543c89 by Pranav Bhandarkar on 03/08/2026 at 16:01..
Fix formatting issues
https://invent.kde.org/qt/clang/llvm/-/commit/50f1e37ff04df1e02d4f0cbb0faf5831bb543c89

Git commit 5bf5520cc2252f5e433b05044deb4b1ff031aaf6 by Pranav Bhandarkar on 03/08/2026 at 16:07..
more formatting fixes
https://invent.kde.org/qt/clang/llvm/-/commit/5bf5520cc2252f5e433b05044deb4b1ff031aaf6