Sort cmake libs/files lists (iree-org#23708)

Formatted using https://github.com/Hardcode84/3

---------

Signed-off-by: Ivan Butygin <[email protected]>

[Codegen] Migrate MapStoreOp to VectorizableOpInterface (iree-org#23662)

The revision also deletes VectorizeIREELinalgExtOps, because it is
already covered in GenericVectorization pass. The tests from
`vectorize_iree_linalg_ext_ops.mlir` are migrated to
`generic_vectorization.mlir`.

The map_store vectorization is only handled on LLVMGPU, which requires
DecomposeMapStoreOp pass, so the vectorization is only enabled on
LLVMGPU for now -- which matches the current behavior in IREE.

It is a step towards
https://lists.lfaidata.foundation/g/iree-technical-discussion/message/15

Assisted-by: Claude

ci-extra: test_torch

Signed-off-by: hanhanW <[email protected]>

Delete LinalgExt::PackOp and LinalgExt::UnPackOp (iree-org#23550)

All the transformations are upstreamed, so we can retire the ops.

Fixes iree-org#20030

ci-extra: test_torch

---------

Signed-off-by: hanhanW <[email protected]>

[docs] Clarify bazelisk use on linux (iree-org#23691)

Installing bazelisk doesn't create an alias for `bazel`, which our
scripts depend on.

Fixes for UBSan compatibility across the runtime (iree-org#23692)

A CI failure in `linux_x64_clang_ubsan` surfaced two categories of UBSan
issues: false positives from the `vptr` sub-check, and real undefined
behavior from function pointer type mismatches.

### vptr false positives

UBSan's `vptr` check uses `typeid()` to verify vtable pointers at every
virtual dispatch. IREE compiles all C++ with `-fno-rtti` for LLVM/MLIR
compatibility, so `typeid()` is unavailable and the check produces false
positives on every virtual call — including gtest internals. This fires
before any test code runs, making the entire UBSan CI configuration
useless for C++ tests.

Fix: exclude `vptr` from UBSan in both CMake (`-fno-sanitize=vptr` on
`CMAKE_CXX_FLAGS`) and Bazel (`--cxxopt=-fno-sanitize=vptr` in
`--config=ubsan`). Applied only to C++ since `vptr` is not relevant to
C.

### Function pointer type mismatches

The runtime had a pervasive pattern of casting typed-pointer functions
to `iree_thread_entry_t` (`int(*)(void*)`) and `iree_condition_fn_t`
(`bool(*)(void*)`) at call sites. This is undefined behavior in C —
calling a function through a pointer to a different function type — even
though it works on every ABI we target. UBSan's `-fsanitize=function`
check catches this and aborts.

Fix: replace all 21 cast sites with thin thunk functions that have the
correct `void*` signature and cast the argument internally. The thunks
are trivially inlineable so there is no runtime cost.

### Notification test race

`RepeatedWaitSignalCycles` assumed a fixed 20ms delay was sufficient for
the worker thread to re-enter `notification_wait` between signal cycles.
With epoch-based level-triggered notifications, a signal that arrives
before `prepare_wait` captures the epoch is invisible to that wait.
There is no way to observe from outside when `prepare_wait` has
executed, so no delay is provably sufficient — any delay-based approach
is fundamentally fragile.

Fix: the main thread now signals continuously (with yields) until the
worker acknowledges each cycle via an atomic counter. If a signal
coalesces before `prepare_wait`, the next one lands after it. Progress
is guaranteed by the retry loop, not by timing. Zero sleeps, zero
delays.

---------

Co-authored-by: Claude <[email protected]>

Integrate llvm/llvm-project@ab10f08 (iree-org#23683)

Integrate up to
llvm/llvm-project@ab10f08

Reapply:
- llvm/llvm-project#183395, it's reverted on
upstream:
llvm/llvm-project@f2cdf3f

[PCF] Add tensor.collapse_shape fusion into pcf.generic/loop (iree-or…

…g#23491)

Fuse tensor.collapse_shape consumers into producer pcf.generic/pcf.loop
ops. This supports all possible dynamic cases by emitting loops along
outer dimensions, effectively unrolling the producer `pcf.write_slice`
ops allowing for continued fusion. The alternative to this (essentially
premature unrolling) is to put the reshape on the sref, though to
continue fusing we still would have to do the same (or propagate the
collapse, which should have already been attempted by this point).

---------

Co-authored-by: Claude Opus 4.6 <[email protected]>

[DispatchCreation] Fix fusion of scalar reduction with consumer (iree…

…-org#23659)

The "reject all-zero maps" check in `getRootParallelLoopToOpMap` was
incorrectly rejecting the scalar-to-scalar case. A map like
`affine_map<(d0) -> (0)>` indicates no dependence on root parallel loops
and should be rejected, but `affine_map<() -> ()>` is a valid
zero-dimensional mapping where there are simply no loops to map.

Signed-off-by: Ian Wood <[email protected]>

A couple of fixes picked up in the fusilli tests using sanitizers. (i…

…ree-org#23617)

This fixes some *SAN issues found in the fusilli tests.

---------

Signed-off-by: Andrew Woloszyn <[email protected]>