[AMDGPU] Testing cleanup in prep for true16 test upstreaming (#209888)
Some small cleanup of a few tests in preparation for True16 test
upstreaming, synchronizes with cleanups that already happened downstream
[LoopUnroll] Remove `Count` from `UnrollingPreferences` (NFC) (#203413)
`UnrollingPreferences` is a way for targets to specify their preferences
to the unroller. The unroller uses `UnrollingPreferences` to guide what
kinds of unrolling to consider while also co-opting it to encode the
specific kind of unrolling it's chosen to attempt.
One preference targets can set is the `Count`, or the number of times
the loop in question will be unrolled:
```
/// A forced unrolling factor (the number of concatenated bodies of the
/// original loop in the unrolled loop body). When set to 0, the unrolling
/// transformation will select an unrolling factor based on the current cost
/// threshold and other factors.
unsigned Count;
```
However, there are no in-tree uses of this functionality, and it does
not work. [Loop
peeling](https://github.com/llvm/llvm-project/blob/112fb2f79d7983be203957cad6b148865182ed47/llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp#L1072)
[21 lines not shown]
[mlir][xegpu] Change inst-data of load/load_matrix to fit lane layout (#209661)
The consumer layout may have multiple distribution of lane data, but
load_gather/load_matrix only allow one single distribution, change their
inst_data according to the single distribution of lane data.
[AggressiveInstCombine] Emit branchless MSB index for de Bruijn ctlz tables (#210633)
When the de Bruijn table's zero element is the bit width minus one it
computes the most significant bit index. We can do that without a branch
using ~ctlz(X) & (InputBits - 1), so the select is no longer needed.
Alive: https://alive2.llvm.org/ce/z/9WsUXd
Fixes #208989
RuntimeLibcalls: Reuse AssemblerPredicate's operators for libcalls (#210651)
Allow specifying RuntimeLibcall's availability in terms of individual
triple properties composed with logical operators.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
ld.elf_so: Fix static TLS alignment on variant II platforms.
Only affects obscure architectures like x86, though.
Sprinkle assertions to make sure this breaks in other ways on other
architectures too, like variant I, or variant II with _lwp_gettcb().
Fair's fair, right?
XXX We should consider verifying that every Elf_Phdr::p_align is
reasonable (i.e., is a power of two, or is zero but only if p_memsz
is also zero), and that p_filesz <= p_memsz, in headers.c for the
main object and in map_object.c for other objects.
PR bin/60469: bin/60469: assertion "ALIGNED_P(q, obj->tlsalign)"
failed: file "/usr/src/libexec/ld.elf_so/tls.c", line 333
[lldb-mcp] Host managed debug sessions in-process (#210450)
Let a client create and own debug sessions with session_create and
session_close. Rather than spawn a separate lldb per session, lldb-mcp
hosts them in its own process, communicating over a loopback socket to
keep things uniform with external lldb instances.
The benefits of this approach are:
- There is no child-process machinery, so nothing needs to be spawned
and cleaned up.
- It works without the need for an external lldb binary.
- It avoids the deadlock by reading stdin through a raw fd instead of
the FILE* stdio path that previously hung the Debugger constructor
contending on the REPL's stdin lock.
- The architecture stays uniform between in-process and external
sessions.
The trade-off is no isolation, so an LLDB crash takes down lldb-mcp
[2 lines not shown]
[MLIR][XeGPU] Add local forward layout propagation (#208932)
Backward layout propagation only assigns layouts to values that are
(transitively) consumed by an anchor op. A value whose only consumer is,
e.g., the next iteration of a loop is left without a layout.
Add a local forward-fill step, run after the backward materialization
walk in propagateLayouts(): it visits ops in producer-first order and,
for any un-laid-out vector result, infers the layout from the op's
already-known operand layouts via a new
inferResultLayoutFromSourceForNonAnchorOp dispatcher (covering
elementwise, transpose, and shape_cast; other ops are left as TODO),
then stamps it with setDistributeLayoutAttr.
---------
Co-authored-by: Claude Opus 4.8 <noreply at anthropic.com>
[CIR][AArch64] Upstream store (vst1_*/vst1q_*) NEON builtins (#209347)
Related to https://github.com/llvm/llvm-project/issues/185382
CIR lowering for store intrinsics (`vst1_*`/`vst1q_*`)
(https://arm-software.github.io/acle/neon_intrinsics/advsimd.html#store)
Port tests:
- `clang/test/CodeGen/AArch64/neon-intrinsics.c`
- `clang/test/CodeGen/AArch64/neon-ldst-one.c`
- `clang/test/CodeGen/AArch64/poly64.c`
- `clang/test/CodeGen/arm-neon-vst.c`
to `clang/test/CodeGen/AArch64/neon/store.c`
[LSV] Don't vectorize load chains across ordered atomics (#208631)
When the LoadStoreVectorizer finds a chain of loads to merge into a
single vectorized load, it hoists all of the constituent loads up to the
location of the first load in the chain.
This is obviously not safe if there are any may-alias stores in the
middle of the chain. But it's *also* not safe if there are `acquire`
*loads* in the middle of the chain.
There's a similar problem with stores. A chain of stores is vectorized
by merging them all into the final store in the chain. This is not safe
if there is an intervening `release` store.
