[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 516a328b737cf4795036d0c661f0916736ff9c33 to 1be72f061f674c2d1a2243d04f8bb092ce0d1fd4
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 89b84291ffc0b7d35f86bfc687f0528e44998a42 by GitHub (on behalf of Jannick Kremer) on 23/07/2026 at 23:28..
[libclang/python] Remove global SPELLING_CACHE alias (#210677)

This completes the second step of
https://github.com/llvm/llvm-project/issues/156680
This change is a follow-up to
https://github.com/llvm/llvm-project/pull/177586, following the release
branching, to ensure a one release-cycle deprecation period.

---------

Co-authored-by: Vlad Serebrennikov <[email protected]>
https://invent.kde.org/qt/clang/llvm-project/-/commit/89b84291ffc0b7d35f86bfc687f0528e44998a42

Git commit bee0671fa8fa2f0f49e0a6c549240ac2da7e8067 by GitHub (on behalf of Jiahao Guo) on 23/07/2026 at 23:37..
[CIR][AArch64] Lower Vector saturating shift and narrow intrinsics (#209389)

### summary

part of : https://github.com/llvm/llvm-project/issues/185382

lower all intrinsics in :
https://arm-software.github.io/acle/neon_intrinsics/advsimd.html#vector-saturating-shift-right-and-narrow
https://invent.kde.org/qt/clang/llvm-project/-/commit/bee0671fa8fa2f0f49e0a6c549240ac2da7e8067

Git commit 490b49fa2bf09948de3967fa6b89d46cf82afe01 by GitHub (on behalf of Jason Molenda) on 23/07/2026 at 23:44..
[lldb] Fix qSpeedTest radix mistake, make number parsings explicit (#211495)

The documentation for qSpeedTest says

```
send packet: qSpeedTest:response_size:response-size;
read packet: data:<response data>

response-size is a hex encoded unsigned number up to 64 bits in size.
```

debugserver implements qSpeedTest as per this documentation, but lldb
sends the number in decimal (base 10), and lldb-server parses it as base
10. I changed lldb and lldb-server to base 16. This is a maintenance
command used by lldb developers exclusivley, so IMO I'm not handling a
migration for old/new servers or defining a new packet or key. I was
running some packet transmission tests with debugserver and noticed
debugserver was sending much larger packets than requested; that's the
kind of failure you see when there is a mismatch.

I audited all uses of `getAsInteger()` that pass a 0 for the radix,
meaning auto-detect the radix, in the gdb-remote dir and changed nearly
all of them to specify either base 10 or base 16. There were two places
where we were using auto-sensing on a base 16 number (and no "0x"
prefix), which would parse incorrectly if an [a-f] letter did not occur.

There is one use of `getAsInteger(0,...)` that is still in place, for
pasing the `qRegisterInfo` eh-frame/dwarf register numbers. Our
documentation for these keys specifies that they may be base 10 or base
16 if prefixed with 0x. This is unlike anywhere else in gdb remote
serial protocol, and smells like something I probably stuck in there 15+
years ago because I've never liked the ambiguity about number bases in
the protocol and I made this half-hearted stab at encouraging use of
"0x".

It is always fun to see the inconsistencies as you review multiple
packets. qProcessInfo returns keys like pid/gid/ppid in base 16.
qfProcessInfo returns the same keys in base 10. qHostInfo returns
cputype/cpusubtype (a Mach-O way of specifying a target cpu) in base 10,
qProcessInfo returns the same keys in base 16. There's so many of these
kinds of little inconsistencies :/
https://invent.kde.org/qt/clang/llvm-project/-/commit/490b49fa2bf09948de3967fa6b89d46cf82afe01

Git commit 1ec7a13fb238f17afd89886071a13f7210ef3583 by GitHub (on behalf of arrowten) on 23/07/2026 at 23:50..
[Sema] Fix assertion in TreeTransform when rebuilding CXXParenListInitExpr (#203715)
https://invent.kde.org/qt/clang/llvm-project/-/commit/1ec7a13fb238f17afd89886071a13f7210ef3583

Git commit 31b6ee93ed0db072a62b4365aeb7c32705c52596 by GitHub (on behalf of Jon Roelofs) on 24/07/2026 at 00:10..
[llvm][AArch64] Enable .cfi_set_ra_state by default for PAuth_LR (#211698)
https://invent.kde.org/qt/clang/llvm-project/-/commit/31b6ee93ed0db072a62b4365aeb7c32705c52596

Git commit 257e81f2e9a67cb857bd6f801e1708c96bee99e4 by GitHub (on behalf of Vitaly Buka) on 24/07/2026 at 00:36..
Revert "[mlir][tosa] Combine unranked/ranked tensor types into single type" (#211701)

Reverts llvm/llvm-project#209737

Breaks bots, see
https://github.com/llvm/llvm-project/pull/209737#issuecomment-5064857765
https://invent.kde.org/qt/clang/llvm-project/-/commit/257e81f2e9a67cb857bd6f801e1708c96bee99e4

Git commit 725737bf88b8219d32e1723ceb653a0e706cc204 by GitHub (on behalf of Karim Alweheshy) on 24/07/2026 at 01:12..
[LLVM] Auto-upgrade legacy coro.end results (#211081)

When `llvm.coro.end` and `llvm.coro.end.async` changed from returning
`i1`
to returning `void` in #159278, the bitcode auto-upgrader continued to
handle
only the older two-argument `llvm.coro.end` form.

As a result, valid bitcode produced before that transition fails
verification
when a current LLVM ThinLTO backend materializes a module containing
either:

* the three-argument, `i1`-returning `llvm.coro.end`; or
* the `i1`-returning `llvm.coro.end.async`.

Teach `AutoUpgrade` to recognize both legacy declarations and rebuild
their
calls with the current `void`-returning intrinsics. If the legacy result
is
used, replace it with `!llvm.coro.is_in_ramp()`, which preserves the old
`true in a resume function, false in the ramp function` behavior. Unused
results require no replacement.

The new assembler test covers used and unused results for both
synchronous
and async coroutine ends.

Tested with:

```console
$ cmake --build build --target opt FileCheck -j8
$ build/bin/opt -S llvm/test/Assembler/auto_upgrade_coro_end_result.ll | \
    build/bin/FileCheck llvm/test/Assembler/auto_upgrade_coro_end_result.ll
```
https://invent.kde.org/qt/clang/llvm-project/-/commit/725737bf88b8219d32e1723ceb653a0e706cc204

Git commit 31f6ba3bedba40939a33b350f50237aa1a0b19f0 by GitHub (on behalf of Sean Perry) on 24/07/2026 at 01:15..
Fix error reported by -Wrange-loop-construct (#211657)

One system I'm building on adds -Wrange-loop-construct to the list of
-W<group> options. This results in the compile error:

```
/home/perry/llvm/Woz/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUMemoryUtils.cpp:37:19: error: loop variable '[ID, N]' creates a copy from type 'std::pair<unsigned int, llvm::MDNode *> const' [-Werror,-Wrange-loop-construct]
  for (const auto [ID, N] : MD) {
                  ^
/home/perry/llvm/Woz/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUMemoryUtils.cpp:37:8: note: use reference type 'std::pair<unsigned int, llvm::MDNode *> const &' to prevent copying
  for (const auto [ID, N] : MD) {
       ^~~~~~~~~~~~~~~~~~~~
                  &
1 error generated.
```
https://invent.kde.org/qt/clang/llvm-project/-/commit/31f6ba3bedba40939a33b350f50237aa1a0b19f0

Git commit 99992e579e072331e336c1690a33c983347f595a by GitHub (on behalf of Susan Tan (ス-ザン　タン)) on 24/07/2026 at 01:17..
[flang][acc] fix array-section reductions on boxed arrays (#211648)

Reduction lowering (genReductions in flang/lib/Lower/OpenACC.cpp) only
remapped the reduced symbol to the acc.reduction result when the object
was a whole array (`isWholeSymbol` guard). For sections, the remap was
skipped, so hlfir.designate for element accesses inside the compute
region kept resolving through the original host declare's box instead of
the private reduction copy — the reduction ran on a private buffer that
never got read back.

Checked and confirmed dropping the boolean is safe for: non-1-starting
sections (recipe already compensates via a deliberate base-pointer
shift), SIZE/UBOUND/LBOUND inside privatized sections (intended
semantics), OPTIONAL dummies (pre-existing TODO, now fails loudly
instead of silently), combined constructs.
https://invent.kde.org/qt/clang/llvm-project/-/commit/99992e579e072331e336c1690a33c983347f595a

Git commit c45be996b8a853294349804bfe14cef3c5f4af10 by GitHub (on behalf of Elvis Wang) on 24/07/2026 at 01:18..
[LV] Simplify Blend/Select chain for tail folding outer loop reductions (#209659)

Predicated tail-folding outer loop reductions will generate a `Blend`
recipe for the predicate in-loop op and a `select` for tail-folding.

E.g.
```llvm
%blend = select %pred.mask, %inloop.op, %red.phi
%sel   = select %header.mask, %blend, %red.phi
```

This patch simplifies this Blend/Select chain to
```llvm
%logical.and = select %header.mask, %pred.mask, false
%sel         = select %logical.and, %inloop.op, %red.phi
```

This enables further optimization opportunities from CSE and further
simplification since the `%header.mask` will become an all-true-mask in
some scenarios (EVL tail-folding).

Alive2 proof: https://alive2.llvm.org/ce/z/NYydvE
PR: https://github.com/llvm/llvm-project/pull/209659
https://invent.kde.org/qt/clang/llvm-project/-/commit/c45be996b8a853294349804bfe14cef3c5f4af10

Git commit 0ee40c546c51b53ec42d94552b346e644e22f020 by GitHub (on behalf of Shanzhi Chen) on 24/07/2026 at 01:20..
[AArch64][SVE] Prefer SVE over scalarization for masked load/store of bf16 vectors (#210986)

During lowering of masked load/store for bf16 fixed-length vectors,
prefer emitting SVE instructions instead of scalarized branching code
whenever "+sve" is enabled in "target-features", regardless of whether
"+bf16" is present. The resulting changes can be seen in the following
test cases.
- llvm/test/CodeGen/AArch64/sve-fixed-length-masked-64-128bit-loads.ll
- llvm/test/CodeGen/AArch64/sve-fixed-length-masked-64-128bit-stores.ll

The direct cause of generating scalarized branching code is that the
"scalarize-masked-mem-intrin" optimization uses isLegalMaskedLoadStore
to determine whether the target natively supports masked load/store
operations. In AArch64TTIImpl::isLegalMaskedLoadStore,
isElementTypeLegalForScalableVector only treats bf16 vector operations
as legalizable when "+bf16" is enabled in "target-features". This
introduces an unnecessary restriction.

Therefore, this patch removes this restriction from
AArch64TTIImpl::isElementTypeLegalForScalableVector and adds or updates
the corresponding tests for all users of this function.

Fixes: #209758
https://invent.kde.org/qt/clang/llvm-project/-/commit/0ee40c546c51b53ec42d94552b346e644e22f020

Git commit fac6cddcb6a0ca10aa0a947c0bf96dace80fb39e by GitHub (on behalf of jxz_hw) on 24/07/2026 at 01:36..
[ARM] support -mlong-calls -fPIC on arm32 (#147313)

support -mlong-calls -fPIC on arm32
try fixing issuse https://github.com/llvm/llvm-project/issues/39970 and
maybe helpful for soving the problem encourted in
https://github.com/llvm/llvm-project/pull/142982
https://invent.kde.org/qt/clang/llvm-project/-/commit/fac6cddcb6a0ca10aa0a947c0bf96dace80fb39e

Git commit 755f3e41de69bcf901f531b086bba6a0a58e5adc by GitHub (on behalf of dong jianqiang) on 24/07/2026 at 01:39..
[ARM] Use .reloc for dso_local weak symbols in PIC mode instead of GOT indirection (#209660)

In ARM ELF PIC mode, weak symbols referenced via the constant pool use a
PC-relative expression like `.long sym-(.LPC+8)`. The assembler eagerly
resolves this when the symbol and reference are in the same section,
which prevents the linker from overriding a weak definition with a
non-weak one from another object file.

The previous approach forced *all* weak symbols through GOT indirection.
That works, but `dso_local` weak symbols with hidden/protected
visibility are non-preemptible — they don't need GOT indirection, and
the extra load is wasteful. This patch emits a `.reloc` directive for
such symbols instead, forcing the assembler to produce an `R_ARM_REL32`
relocation while keeping a direct PC-relative reference from the
constant pool.

Default-visibility weak symbols (even `dso_local`) remain routed through
the GOT because they stay exported and preemptible in shared objects,
and `R_ARM_REL32` against an external symbol cannot be used when making
a shared object.

Fix #209244
https://invent.kde.org/qt/clang/llvm-project/-/commit/755f3e41de69bcf901f531b086bba6a0a58e5adc

Git commit 050c2ef1113becfd9a8464e7474da00a745599b5 by GitHub (on behalf of Vitaly Buka) on 24/07/2026 at 02:23..
Reland "[mlir][tosa] Combine unranked/ranked tensor types into single type" (#211708)

Reverts llvm/llvm-project#211701
Relands llvm/llvm-project#209737

The buildbot failure was misattributed to this change.
Real cause is https://github.com/llvm/llvm-project/pull/207274
https://invent.kde.org/qt/clang/llvm-project/-/commit/050c2ef1113becfd9a8464e7474da00a745599b5

Git commit cad3c95a89c48d714a71f6e8b4af6f3e3ab100ea by GitHub (on behalf of hev) on 24/07/2026 at 02:23..
[LoongArch] Support i128 operands for LSX inline assembly (#211464)

Allow `i128` values to be used with the `f` inline assembly constraint
when targeting LSX.

Although `i128` is not a legal LSX value type, it naturally maps to a
single 128-bit LSX vector register for inline assembly. This enables
instructions such as `vadd.q` to operate directly on `__int128` operands
without requiring explicit vector types.
https://invent.kde.org/qt/clang/llvm-project/-/commit/cad3c95a89c48d714a71f6e8b4af6f3e3ab100ea

Git commit 30fb6a7b7624024db9edcb88219b65289e72e571 by GitHub (on behalf of Akshay K) on 24/07/2026 at 02:53..
[X86] Don't emit x87 register scrub when x87 is unavailable (#211146)

### Summary

`-fzero-call-used-regs=all` always emits the x87 `fldz`/`fstp` scrub
sequence, without checking whether x87 is enabled. In a function built
with `-mno-x87` or `-msoft-float`, this injects 16 `x87` instructions
into a translation unit that must not touch the FPU:

```asm
// test.c
int f(int x) { return x + 1; }

$ clang -O2 -S -mno-x87 -msoft-float -mno-sse \
        -fzero-call-used-regs=all --target=x86_64-linux-gnu test.c -o -
f:
        leal    1(%rdi), %eax
        fldz
        ...          # 8x fldz
        fstp    %st(0)
        ...          # 8x fstp %st(0)
        xorl    %ecx, %ecx
        ...
        retq
```
Reproducer: https://godbolt.org/z/xqjzj9rx7

Without -fzero-call-used-regs, no x87 instructions are emitted:
https://godbolt.org/z/qoenEb33j

This is problematic for kernels, firmware, and EFI environments, which
commonly compile with the FPU disabled or not context-switched. Emitting
x87 instructions in these configurations can cause the FPU state to
fault or become corrupted.

### Fix
Skip the x87 scrub in `emitZeroCallUsedRegs` when x87 is unavailable
(`useSoftFloat()` or `!hasX87()`). In those configurations, the x87
register stack cannot contain program values, so there is nothing to
clear.

Add `zero-call-used-regs-soft-float.ll` to verify that a `-msoft-float`
function still zeroes the requested general-purpose registers while
emitting no x87 instructions. The full X86 CodeGen test suite passes,
and code generation for x87-enabled targets is unchanged.

This issue was discovered while investigating #211064, in which x87
return values were clobbered by the same scrubbing logic. Both issues
originate in the x87 handling within emitZeroCallUsedRegs, but they are
independent and are addressed in separate changes.
https://invent.kde.org/qt/clang/llvm-project/-/commit/30fb6a7b7624024db9edcb88219b65289e72e571

Git commit fec36790e2a09168aa85493d029d5fbfde3e11c0 by GitHub (on behalf of Bryth) on 24/07/2026 at 02:54..
[mlir][VectorToLLVM] Fix comment still referring to undef instead of poison (NFC) (#211196)

When updating operators from undef (deprecated) to poison, the
associated comment wasn't updated accordingly. This PR fixes it.
https://invent.kde.org/qt/clang/llvm-project/-/commit/fec36790e2a09168aa85493d029d5fbfde3e11c0

Git commit 4f8de7694a0aab7a55c21970855dd8659f3700c6 by GitHub (on behalf of Jin Huang) on 24/07/2026 at 04:04..
[profcheck][coro] Adding Branch weights PGO in Coroutines Passes (#184466)

The CoroSplit and CoroFrame generate several control flow instructions
(`br`, `select`, `switch`) that previously lacked `!prof` branch weight
metadata.

When a coroutine is split, most basic blocks are simply cloned into the
generated functions (`.resume`, `.destroy`, and `.cleanup`) and don't
actually change their internal structure or layout. This PR changes:

1. Dispatch Branch Weights:
Since the original coroutine already ran through PGO, we already have
the `SuspendFreqs` records telling us exactly how many times each
suspension point was executed in the real world.

In the new clone `.resume` functions, the compiler generates new routing
`switch` instruction to direct the traffic. Instead of guessing the
probabilities for these new routes, we simply look back at the
`SuspendFreqs` records, calculate the exact execution frequency and
directly onto the new routing `switch` instructions as `!prof` data.

2. Function Entry Count:
We compute the entry count for the generated `.resume` function by
summing up the frequencies of all suspension target blocks, ensuring the
`.resume` function's entry metadata accurately reflects its true
invocation frequency rather than inheriting original counts. Two new
test cases is added see:
    ```

llvm/test/Transforms/Coroutines/coro-split-resume-entry-count-no-suspend.ll
    llvm/test/Transforms/Coroutines/coro-split-resume-entry-count.ll 
    ```

3. Others updates add branch weight metadata in several locations within
these passes:

* **CoroSplit.cpp**: 
* `handleFinalSuspend`: Added an equal (50/50) weight to conditional
branches handling final-suspend conditions via
`setExplicitlyUnknownBranchWeightsIfProfiled`.

* `updateCoroFrame`: Adds an equal (50/50) weight to the select
instruction that chooses either the `destroy` or `cleanup` function by
using `setExplicitlyUnknownBranchWeightsIfProfiled`.

* **CoroFrame.cpp**: 
* `rewritePHIsForCleanupPad`: Adds a branch weight of {0, 1, 1} to
two-way switch instructions driven by PHI nodes generated in the EH
dispatch block (.corodispatch). This provides accurate probabilistic
information for `SimplifyCFG`, which typically translates such `switch`
  ```
cleanup2.corodispatch: ; preds = %catch.dispatch.2, %handler2
    %1 = phi i8 [ 0, %handler2 ], [ 1, %catch.dispatch.2 ]
    %2 = cleanuppad within %h1 []
    switch i8 %1, label %unreachable [
      i8 0, label %cleanup2.from.handler2
      i8 1, label %cleanup2.from.catch.dispatch.2
    ]
  ```
    into `icmp` + `br`.
  
  ```
cleanup2.corodispatch: ; preds = %catch.dispatch.2, %handler2
    %1 = phi i8 [ 0, %handler2 ], [ 1, %catch.dispatch.2 ]
    %2 = cleanuppad within %h1 []
    %3 = icmp eq i8 %1, 0
br i1 %3, label %cleanup2.from.handler2, label
%cleanup2.from.catch.dispatch.2
  ```
* **CoroCleanup.cc**
* Setting the `unknown` profile to `NoopFn`/`__NoopCoro_ResumeDestroy`
to avoid the false warnings. because this function is generated by this
the pass, PGO has no profile count for it.

Co-authored-by: Jin Huang <[email protected]>
https://invent.kde.org/qt/clang/llvm-project/-/commit/4f8de7694a0aab7a55c21970855dd8659f3700c6

Git commit 8e075ecfc01b0ab6e87b3cfa1aea5acf58edd6e9 by GitHub (on behalf of Aiden Grossman) on 24/07/2026 at 04:37..
[ProfCheck] XFail 3 coro tests (#211719)

These are still failing after 4f8de7694a0aab7a55c21970855dd8659f3700c6.
https://invent.kde.org/qt/clang/llvm-project/-/commit/8e075ecfc01b0ab6e87b3cfa1aea5acf58edd6e9

Git commit 1be72f061f674c2d1a2243d04f8bb092ce0d1fd4 by GitHub (on behalf of Austin Kerbow) on 24/07/2026 at 05:02..
[AMDGPU] Fix gfx1250 WMMA latencies (#202522)

- 16x16x64 FP8/BF8 WMMA run in 4 cycles, not 8. Add a 4-cycle
WriteXDL1PassWMMA write and split the FP8/BF8 InstRW by shape so that
16x16x128 FP8/BF8 (and F16/BF16) keep the 8-cycle latency.
- f8f6f4 WMMA run in 4 cycles when both matrix inputs are f4 and 8
cycles when any input is f6 or f8, instead of the previous 8/16. Update
the scheduling predicate accordingly.
https://invent.kde.org/qt/clang/llvm-project/-/commit/1be72f061f674c2d1a2243d04f8bb092ce0d1fd4