[SPIRV] Fix inconsistent operand order for counter resource intrinsic (#221646)
The `llvm.spv.resource.handlefrombinding` intrinsic stores its binding
operands in the order (DescriptorSet, BindingNo, ...). The
`llvm.spv.resource.counterhandlefrombinding` intrinsic should use the
same order.
The `llvm.spv.resource.counterhandlefrombinding` intrinsic is currently
emitted only by the `SPIRVLegalizeImplicitBinding` pass. The pass
previously built its operands in the wrong order, and the instruction
selector repeated the same inversion when emitting decorations.
This change makes the operand order consistent with
`llvm.spv.resource.handlefrombinding`.
Test update closes a coverage gap - there were no tests for explicit
`llvm.spv.resource.counterhandlefrombinding` calls.
Assisted by GPT-5.6 Sol.
[clang] Warn on signed char array constant conversion (#203792)
This resolves #181730: fixes a missing `-Wconstant-conversion`
diagnostic for `signed char` array initialization.
Before this change, Clang warned for `signed char foo = 255;` but did
not
warn for `signed char bar[] = {255};`.
The warning suppression helper did not distinguish between `char`,
`unsigned char`, and `signed char` in brace-initialized arrays. Now it
does.
[Clang][OpenACC] Fixed getExtValue Call on Invalid Gang Dim (#221502)
**Problem**
When an invalid 'gang dim' value is used in `CheckGangDimExpr`, the
function prints the value into the diagnostic message by calling
`getExtValue`. This function asserts on values that can't fit into a
signed integer.
**Solution**
`APSInt` has a `<<` operator anyway so just use that.
The fix causes the message to print with the following formatting:
```
test.cpp:5:40: error: argument to 'gang' clause dimension must be 1, 2, or 3: evaluated to 18'446'744'073'709'551'574
5 | #pragma acc routine(S::foo) gang(dim : S::foo())
| ^
1 warning and 1 error generated.
```
Fixes #221418
[CIR] Fix CIR tests by adding a triple/Requires. (#222346)
Now that we're trying to build by default, we actually have to be able
to build on other buildbots! But since we still don't have the
ABI/target stuff for non linux, we need to make sure our tests don't hit
that. Tests that execute 'clang' in some way are given a triple, ones
that are on .cir files we just add a 'requires'. Some day we should be
able to remove those, but it'll require us to add the cxxabi/etc for
windows.
[AMDGPU] Model GFX1250 VALU blocking cycles
Some gfx1250 VALU instructions block the VALU pipe for N cycles, and
the CoExec scheduler must model that occupancy. The existing SchedModel
cannot represent this given current modelling constraints (see #202775).
Attach GFX1250BlockingCycles to the VOP instruction definitions and
emit a searchable table so SIInstrInfo::getBlockingCycles() can report
the occupancy. CoExec uses that to classify multi-cycle VALU and to
account for blocking when computing HWUI cycles.
Authored by Jeffrey Byrnes <jeffrey.byrnes at amd.com>
[mlir] Reuse the MLIRIR PCH through dependencies (NFC)
Track whether an MLIR library's link closure reaches MLIRIR and reuse the
MLIRIR PCH for those libraries. Preserve higher-priority local PCHs and add an
explicit opt-out for targets whose sources are incompatible with reuse.
Relative to the core and LLVM dialect PCH parent, clean Release builds of LLVM
and MLIR with Ninja -j16 pinned to CPUs 16-31 improved as follows:
wall: 398.79s -> 386.47s (-3.09%)
user: 5789.14s -> 5624.02s (-2.85%)
system: 455.05s -> 438.45s (-3.65%)
Assisted-by: Codex
[mlir][LLVM] Reuse a PCH for MLIRLLVMDialect (NFC)
Build a private precompiled header from the LLVM dialect and LLVM IR headers
and use it for MLIRLLVMDialect. Build dialect libraries before conversions so
the PCH is available early and repeated parsing is avoided.
Relative to the MLIRIR PCH parent, clean Release builds of LLVM and MLIR with
Ninja -j16 pinned to CPUs 16-31 improved as follows:
wall: 420.41s -> 398.79s (-5.14%)
user: 6125.97s -> 5789.14s (-5.50%)
system: 481.88s -> 455.05s (-5.57%)
Assisted-by: Codex
[mlir] Reuse a precompiled header for MLIRIR (NFC)
Build a private precompiled header from the common MLIR IR headers and use it
for MLIRIR. Build Support and IR first so the PCH is available early, and
qualify the LLVM LSP Location name that the broader header surface exposes.
On current main, clean Release builds of LLVM and MLIR with Ninja -j16 pinned
to CPUs 16-31 improved as follows:
wall: 535.99s -> 420.41s (-21.56%)
user: 7550.29s -> 6125.97s (-18.86%)
system: 569.85s -> 481.88s (-15.44%)
Assisted-by: Codex
L2ARC: do not feed a device while its rebuild is pending
l2arc_add_vdev() leaves the device at l2ad_start with l2ad_first set,
marks it l2ad_rebuild, and starts its feed thread. The rebuild runs
later from the spa async thread and only then restores the geometry the
on-disk header describes.
A feed in that window writes at l2ad_start believing the device is
empty, and its headers go on the head of l2ad_buflist while the rebuild
appends the restored ones at the tail. l2arc_evict() walks that list
from the tail and stops at the first header outside the range it is
clearing, so once list position stops tracking device offset the walk
exits early, headers the hand is about to overwrite are never destroyed,
and the writes that replace them charge the space twice. vs_alloc
passes vs_space and zpool(8) reports 16.0E free.
l2arc_dev_invalid() rejected a device with l2ad_rebuild or l2ad_trim_all
set until b525525b4 made the feed threads per-device; neither flag has
had a reader since. Restore the test, after SCL_L2ARC is taken so it
[7 lines not shown]
AMDGPU: Migrate R600 onto generated TargetParser bitset (#222461)
Follow the new amdgcn system so we don't have to carry 2 different
forms of this infrastructure.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
