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

Git repository change summary for qt/clang/llvm
Pushed by mirror-service into branch 'upstream/users/shiltian/nfc-sgpr-spill-rename'.
Changed from 0000000000000000000000000000000000000000 to 136b116b12a24efcb0d374660050fb187b9129b8
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 a805dd6fc5285fe2fdc911e38a12fe704e40fece by GitHub (on behalf of agozillon) on 03/08/2026 at 23:19..
[Flang][OpenMP][OpenMPIRBuilder] Implement module scope declare target use rewrite mechanism (#212920)

During lowering of declare target'd variables we generate new global
variables for device that replace the use of the pre-existing global
variable. In Flang we currently rewrite this for each target region, but
that's not enough to cover indirect use cases inside of declare target
functions which can be imported into the module and utilised inside of a
target region. This PR tries to extend the scope of the rewriting to the
module than a per target region rewrite.

It does so by creating a mechanism where we can register globals for
replacement which will trigger on finalization of the OMPIRBuilder. This
is required as due to the ordering of lowering for MLIR, where we
generate the replacement global at the beginning of the module before
any uses have been generated, effectively meaning we cannot replace the
uses at that point. So, we defer the replacement to the OMPIRBuilder as
there is no deferral mechanism directly in the OpenMP MLIR lowering.

The alternative might be to rebind the global maps in ModuleTranslation
(which requires extending ModuleTranslation a bit and might not be
looked apon as a great alteration from the MLIR community) so that the
old global points to the new one, but in practice this doesn't work
particularly well for declare target link/usm variables as they
neccesitate a load and the act of rebinding the global doesn't indicate
to the lowering that the load is required. So, the OMPIRBuilder method
allows us more flexibility to make this (and other) required
alterations.
https://invent.kde.org/qt/clang/llvm/-/commit/a805dd6fc5285fe2fdc911e38a12fe704e40fece

Git commit f7b7ec8d5542dcede1ae607aa74dfe36d7a3c530 by GitHub (on behalf of Zachary Yedidia) on 03/08/2026 at 23:26..
[MC][X86] Reintroduce aligned instruction bundling (#175830)

Aligned bundling partitions instructions into fixed-size, naturally
aligned groups called bundles and guarantees that no instruction
crosses a bundle boundary, giving the instruction stream a single
canonical decoding. It is a building block for software-based fault
isolation: control flow cannot jump into the middle of an instruction
to manufacture a different, unchecked sequence, and when combined with
masking of indirect branch targets it constrains control flow to a
statically verifiable set of locations.

The previous target-independent implementation was removed in #148781,
which simplified MC by eliminating per-fragment BundlePadding, the
virtual emitInstToData, and BundleGroupBeforeFirstInst. This change
reimplements the feature in the X86 backend on top of the existing
MCBoundaryAlignFragment infrastructure added for branch alignment,
keeping the generic MC surface smaller:

* AsmParser parses .bundle_align_mode, .bundle_lock and .bundle_unlock
  and dispatches them through new MCStreamer hooks.
* MCAssembler holds the bundle size, MCObjectStreamer tracks whether a
  locked group is open, and MCBoundaryAlignFragment gains an
  align_to_end bit. No new per-fragment padding state.
* Padding is decided at layout time by computeBoundaryAlignSize, which
  pads only when an instruction or a locked group would cross a
  boundary, and NOP emission goes through writeControlledNops.
* X86AsmBackend opens a boundary-align fragment for each instruction, or
  one for a whole bundle-locked group, and reports the group size error
  at layout.

Improvements over the prior implementation:

* NOPs never span a bundle boundary.
* Labels never move.
* Bundle locks may not nest.
* Padding can be folded into neighboring instructions as otherwise
  ignored prefixes rather than standalone NOPs, reusing the existing
  --x86-pad-max-prefix-size option. Padding is only ever traded within
  the bundle that holds it, so nothing moves across a boundary.
* No codegen change and no extra layout work when the directives are not
  used.

Bundling is supported for X86 ELF only and the directives are rejected
elsewhere. Restrictions: bundle mode may be set once per file and cannot
be changed or turned off, it is incompatible with -x86-align-branch and
-mbranches-within-32B-boundaries, locked groups are allowed only in
executable sections, must fit within one bundle, must be closed before a
section change, and may not end in a bare instruction prefix.

Documented in llvm/docs/AlignedBundling.rst, with tests in
llvm/test/MC/X86/AlignedBundling.

---------

Co-authored-by: Taehyun Noh <[email protected]>
Co-authored-by: Fangrui Song <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/f7b7ec8d5542dcede1ae607aa74dfe36d7a3c530

Git commit b010a18d2b648cab83c83967ff26b8fde11acdc6 by GitHub (on behalf of Jeff Niu) on 03/08/2026 at 23:50..
[mlir][ODS] Allow parameters on side-effect resources (#213792)

Assisted-by: OpenAI Codex

---------

Co-authored-by: jeffniu-openai <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/b010a18d2b648cab83c83967ff26b8fde11acdc6

Git commit d667528a1d9d73f4aa3c627295ae017699890ce1 by GitHub (on behalf of Nico Weber) on 04/08/2026 at 00:03..
[gn build] Port 2354dce21ab1 (#213803)
https://invent.kde.org/qt/clang/llvm/-/commit/d667528a1d9d73f4aa3c627295ae017699890ce1

Git commit 3cdc913f989ebe7f044b1bf5debb91b5fa9cd47e by GitHub (on behalf of Nico Weber) on 04/08/2026 at 00:03..
[gn build] Port f84bacf82a15 (#213804)
https://invent.kde.org/qt/clang/llvm/-/commit/3cdc913f989ebe7f044b1bf5debb91b5fa9cd47e

Git commit 1d3ea0f50c4bcfababe7929c913df500723dcf2f by GitHub (on behalf of Arun Thangamani) on 04/08/2026 at 00:12..
[ADT] Fix - gcc warning: buf may be used uninitialized [-Werror=maybe-uninitialized] (#213578)

When compiled with `gcc`, the uninitialized `buf` triggers a warning.
Since some external projects (e.g., `TPP-MLIR`) treat warnings as
errors, the build fails. This patch initializes `buf` to eliminate the
warning and prevent those build failures
https://invent.kde.org/qt/clang/llvm/-/commit/1d3ea0f50c4bcfababe7929c913df500723dcf2f

Git commit 275c9efb8cea7e0a6cdbb96a2a464a1566649fe7 by GitHub (on behalf of Joseph Huber) on 04/08/2026 at 00:14..
[Offload] Add `--kernel <name>` command to `llvm-gpu-loader` (#213738)

Summary:
This makes it easier to test a single function without opting-in to the
whole `crt1.o` infra for `libc` that was originally intended to test
existing CPU tests. Good for possible future unit tests, cheap tool that
can launch a kernel. Only provides `foo(void)` kernels for now, can be
improved.
https://invent.kde.org/qt/clang/llvm/-/commit/275c9efb8cea7e0a6cdbb96a2a464a1566649fe7

Git commit 38146e816a08d24f95b04e1940b362616fb4a075 by GitHub (on behalf of Zhen Wang) on 04/08/2026 at 00:16..
[flang][cuda] Only register module variables defined in the current translation unit (#213720)

CUFAddConstructor registered every CUF module variable mirrored in the
GPU module, including variables brought in with USE from another
translation unit. Without relocatable device code each translation unit
has its own device module, so registering a declaration binds the host
address to a module that does not contain the symbol, and a later
cudaGetSymbolAddress fails with cudaErrorInvalidSymbol or
cudaErrorSymbolNotFound. Under unified memory the same declaration is
registered as host memory, overriding the defining unit's device
registration.

Skip globals that have no initializer and no body. Non-allocatable
managed globals still register, since they go through a companion
pointer local to the translation unit.
https://invent.kde.org/qt/clang/llvm/-/commit/38146e816a08d24f95b04e1940b362616fb4a075

Git commit 04a123b17c1ab097e3475da53a7e485c7b184a04 by GitHub (on behalf of Abhinav Gaba) on 04/08/2026 at 01:23..
[OpenMP][Clang] Enable `ATTACH`-style maps for mappers. (#210213)

This is a follow-up to #153683 to support OpenMP compliant
pointer-attachment
in `declare_mappers` via `ATTACH`-style maps.

In addition to enabling attach-style maps, we also need to propagate
information about
which map entries are for "pointee" data, i.e. have an "attach-ptr", and
thus occupy a different storage block than the base variable for which
the mapper is being generated. e.g.

```c

S sa[10];
#pragma omp declare_mapper (default: S s) map (s.x, s.p[0:10])

#pragma omp target_enter_data map(sa)
```

The entry emitted for `s.p[0:10]` is for the pointee, i.e. it does not
share storage with `s`.
Mapper codegen needs to know that the entry for `sa[1].p[0:10]`, for
example, is not a `MEMBER_OF` the map of `sa`, as it occupies its own
storage and has its own ref-count tracking etc.


Flang currently passes an unconditional `PreserveMemberofFlags` bool to
the OMPIRBuilder function, which should eventually be propagated to
using the per-entry information so that `map(s%x)` should get MEMBER_OF
during mapper codgen, but `map(s%p(1:10))` should not. Currently, the
per-entry MapInfo field is set to `false` for flang, so the change is a
no-op for it. I don't have enough flang expertise/testing resources, so
I'll let Andrew update Flang in follow-up changes.

---------

Co-authored-by: Claude Opus 4.8 <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/04a123b17c1ab097e3475da53a7e485c7b184a04

Git commit eb50d8775ce52576595b4e01583ec6e8c0842c6d by GitHub (on behalf of Prasoon Kumar) on 04/08/2026 at 01:30..
[lit] Run builtin cat / diff in-process instead of spawning (#208024)

cat and diff are the only two builtins that still spawn a subprocess:
every cat/diff on a RUN line spawns a fresh Python interpreter, which
dominates wall time given how small lit's typical inputs are. Run them
in-process instead.

The spawned-script path stays as a fallback for now. Removing it
entirely is a follow-up PR. Output is byte-identical to the spawn path
either way.
https://invent.kde.org/qt/clang/llvm/-/commit/eb50d8775ce52576595b4e01583ec6e8c0842c6d

Git commit 8f82ba2c79f4e6a69a884cc9e19bd0b8c0bbe932 by GitHub (on behalf of Kewen Meng) on 04/08/2026 at 03:08..
Revert "clang: Use TargetID parsing from AMDGPUTargetParser" (#213824)

Reverts llvm/llvm-project#209845

verified by local reverting

unblock bots: 
https://lab.llvm.org/buildbot/#/builders/234/builds/1391
https://lab.llvm.org/buildbot/#/builders/10/builds/33193
https://invent.kde.org/qt/clang/llvm/-/commit/8f82ba2c79f4e6a69a884cc9e19bd0b8c0bbe932

Git commit ff6d537b14d737719d6377789784d04ff9565f65 by GitHub (on behalf of Kane Wang) on 04/08/2026 at 03:10..
[RISCV] Pick correct lround libcall for fp128 (#213220)

**LROUND** with an i32 result on rv64 chose the libcall as `f64 ?
LROUND_F64 : LROUND_F32`, so **fp128** fell through to the f32 libcall
(lroundf) and lost precision. Use `RTLIB::getLROUND`, which maps
**fp128** to lroundl.
https://invent.kde.org/qt/clang/llvm/-/commit/ff6d537b14d737719d6377789784d04ff9565f65

Git commit ac19ad6217d18209bc3633ed3130db237596976d by GitHub (on behalf of Shilei Tian) on 04/08/2026 at 04:08..
[AMDGPU] Support partial and empty WWM pools for SGPR spills (#213491)

SGPR lane spilling currently treats the WWM VGPR pool as all-or-nothing.
This can fail compilation when the requested pool cannot be formed, even
though scratch spilling or a smaller spillable pool could make progress.

This PR lets ordinary SGPR spills fall back to scratch when the pool is
empty and lets WWM register allocation use a nonempty partial pool. It
keeps the full-pool requirement for strict WWM/WQM and explicit
spill-carrier preallocation.

The no-pool fallback is recorded in SIMachineFunctionInfo so frame
lowering can provide enough emergency scavenging slots. The state is
also serialized to preserve the behavior across MIR round trips.

Fixes LCOMPILER-2542.
https://invent.kde.org/qt/clang/llvm/-/commit/ac19ad6217d18209bc3633ed3130db237596976d

Git commit 136b116b12a24efcb0d374660050fb187b9129b8 by Shilei Tian on 04/08/2026 at 04:09..
[NFC][AMDGPU] Rename some variable names to follow convention better

This is a follow-up of #213491.
https://invent.kde.org/qt/clang/llvm/-/commit/136b116b12a24efcb0d374660050fb187b9129b8