[RISCV] Don't overcost wide load in optimized segment load/store (#207146)
With the +optimized-nfX-segment-load-store tuning flag, we cost a
segmented store as a single wide load + some shuffle ops.
However for e.g. a `<vscale x 5 x i64>` Factor=5 segmented load, a wide
`<vscale x 5 x i64>` load gets costed as a full LMUL 8 load.
From what I can see on
https://camel-cdr.github.io/rvv-bench-results/spacemit_x100/index.html
and on my own measurements on the spacemit-x60, uarchs likely don't do a
full LMUL 8 load under the hood and instead dispatch the minimum number
of DLEN sized ops needed for the full segment.
This changes the wide load cost to be divideCeil(vector size, DLEN) ops
so we don't overcost it.
Whilst we're here, this also removes the LT.first legalization
multiplier. We're computing the cost in terms of the unlegalized type so
we shouldn't be scaling it by the legalization cost.
[orc-rt] Add Proxy, a protocol-agnostic controller-call handle (#217792)
Introduce Proxy<RetT(ArgTs...)>, a typed handle for invoking a
controller-side operation from the executor. A Proxy abstracts over how
a call reaches the controller: it holds an opaque callee tag and a
dispatch function (supplied by a per-protocol spec) and forwards calls
through the Session.
This is a cut-down port of llvm/ExecutionEngine/Orc/Proxy.h, with two
deliberate differences:
- The callee is identified by an opaque tag (const void *, typically the
address of a controller-side global) rather than an ExecutorAddr, since
the executor->controller direction dispatches by tag.
- Only the asynchronous (OnComplete) call operator is provided. The
blocking convenience operator is omitted: the executor may be
single-threaded or freestanding and cannot rely on std::promise/future
or on blocking a dispatch thread.
[2 lines not shown]
[SSAF] Fix a stage2 test failure with ASan-instrumented clang - continued
The previous effort in PR#211432 that disables ASan for one static
global is not sufficient. This commit disables ASan for the whole test
plugin.
rdar://182623740
[bazel] Select Windows GNU BLAKE3 assembly for clang-cl (#217695)
## Motivation
This PR is motivated by ongoing work of providing a fully hermetic
clang-cl bazel toolchain built for windows with the MSVC runtime.
The LLVM Bazel overlay does not select a Windows-compatible BLAKE3
assembly source set for an x86_64 Windows target compiled with the
rules_cc `clang-cl` compiler dialect.
The `windows_gnu.S` name can be misleading here. "GNU" describes the
assembly syntax accepted by GNU-style assemblers and Clang's integrated
assembler; it does **not** mean that the implementation uses the MinGW
ABI or runtime. These files implement the Microsoft x64 calling
convention and are intended to produce Windows COFF objects.
A hermetic clang-cl toolchain can therefore assemble the GNU-syntax
Windows sources directly. Selecting the MASM-syntax `windows_msvc.asm`
[25 lines not shown]
*/*: Bump PORTREVISION for known Qt private API abusers
Qt 6.11.2 edition.
These ports are known to directly use or link to a library that uses the
Qt private API and must be rebuilt with every Qt update.
Qt *public* API/ABI compatability is excellent, so most consumers don't
need to necessarily be rebuilt between patch or even minor releases, but
use of the private API breaks this compatibility between even patch
releases and its use is highly discouraged.
This list [1] is based on histortical data. We don't have time to
revisit every port on the list with each Qt update, so if your port has
dropped Qt private headers and was bumped in error, please remove it
yourself if you have write access to the Wiki or alert someone on kde@.
[1] https://wiki.freebsd.org/KDE/Qt
MFH: 2026Q3
Qt6: Update to 6.11.2
Aug 18, 2026 by Jani Heikkinen
Qt 6.11.2 is now available for download. As a patch release, Qt 6.11.2
doesn’t introduce new features, but it delivers around 400 bug fixes,
security improvements, and quality enhancements on top of Qt 6.11.1.
For a full overview of the most notable changes, take a look at the
Qt 6.11.2 release notes.
Announcement:
https://www.qt.io/blog/qt-6.11.2-released
Release notes:
https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.11.2/release-note.md
PySide6: Update to 6.11.2
MFH: 2026Q3
Security: a188c081-9ce8-11f1-8fc6-cb9659fdabad
tests/sys/posixshm/posixshm_test.c::accounting fix after st_size changes
st_blksize is defined by POSIX as the 'preferred I/O block size for this
object.' It is wrong to use st_blksize as the unit for st_blocks and
expect it to be equal to the object size regardless of the change of
st_blksize.
Fixes: 3a1bf59d195c ("shmfd: consistently return size in 512 byte blocks for fstat(2) st_blocks")
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D59014
[docs] Fix CMAKE_CROSSCOMPILING spelling in HowToCrossCompileLLVM (#217623)
## Summary
The HowToCrossCompileLLVM option list spelled the CMake variable as
`CMAKE_CROSSCOMPIILING` (extra I). The linked CMake docs use
`CMAKE_CROSSCOMPILING`.
Assisted-by: Grok (xAI)
Improve compiler-rt build structure and export compilation info (#190088)
This first improves the structure of the compiler-rt BUILD.bazel, fixing
bugs and exposing more carefully arranged source files.
It also exposes compilation info for builtins and CRT files for use in
compiling these source files.
[mlir][acc] Keep worker-only launches unaligned in ACCCGToGPU (#217382)
Example:
```fortran
!$acc parallel loop worker reduction(+:s) num_workers(16) vector_length(8)
```
In this code, a ThreadY reduction forced blockDim.x to a warp, and
blockDim.y
was divided by the same factor to hold the thread count, so the launch
ran as
(32, 4, 1): 4 workers instead of 16, with the folded-away workers turned
into
ThreadX lanes redoing each other's work.
Fix: skip the alignment when only the workers ask for it and the row
width
divides the subgroup size. Worker reductions combine their partials in
the
[6 lines not shown]
[VPlan] Fix replaceWithFinalIfReductionStore assert with multiple reductions (#217316)
A reductions final value can be simplified away to a constant, which
https://github.com/llvm/llvm-project/pull/201023 handled in
replaceWithFinalIfReductionStore.
However constant live ins can have other users, e.g. a different
reductions start value, in which case the assertion will fail because
we're comparing the backedge value of a different reduction entirely.
Relax the assertion to allow any VPIRValue instead
This an alternative to https://github.com/llvm/llvm-project/pull/217306
that fixes #215071
