nvme: collapse the per-counter qpair statistic sysctl handlers
A single handler that takes the counter's offset
within struct nvme_qpair in arg2.
No functional change
Reviewed by: imp, adrian
Differential Revision: https://reviews.freebsd.org/D60020
nvmf: factor out the pending request abort loop
The routine is entered with the namespace lock held and drops it before
completing the requests, which preserves the existing locking.
Reviewed by: imp, adrian
Differential Revision: https://reviews.freebsd.org/D60019
nvme: share one handler between the interrupt coalescing sysctls
The int_coal_time and int_coal_threshold handlers differed only in which
controller field they updated before reprogramming the feature.
Reviewed by: imp, adrian
Differential Revision: https://reviews.freebsd.org/D60018
sysvshm: Fix locking in shm_prison_set()
We were not acquiring the global sysvshm lock when handling cleanup of
sysvshm segments. Acquire the lock in shm_prison_cleanup() instead, to
be consistent with the sysv semaphore code.
Reviewed by: jamie
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60030
[TBAA] Recover !tbaa for a memcpy of struct with same type fields (#214116)
When InstCombine widens a small same-typed aggregate copy into an
integer load/store, it derives no !tbaa, and !tbaa.struct is nulled out,
so the load/store are left untyped. An untyped access may-alias every
typed access and blocks optimization:
struct Coord { int x, y; };
void copy_if_inbounds(Coord *dst, const Coord *src, const long *bound,
int n) {
for (int i = 0; i < n; ++i)
if (i < *bound)
dst[i] = *src; // {int,int} copy -> memcpy + !tbaa.struct
}
compare this to field-by-field copy, which has typed field access
void copy_fields_if_inbounds(Coord *dst, const Coord *src, const long
*bound, int n) {
for (int i = 0; i < n; ++i)
[2 lines not shown]
multimedia/jellyfin-ffmpeg: opencl needed for Jellyfin's HDR tone mapping
Jellyfin does AMD VAAPI HDR tone mapping with libplacebo, not OpenCL. However,
EncodingHelper.GetVaapiVidFilterChain() has an early-exit guard before it ever
selects the AMD branch
It need 2 patches:
- OpenCL (Jellyfin's IsOpenclFullSupported gate)
- overlay_vulkan framesync patch (Jellyfin's IsVulkanFullSupported gate)
PR: 298857
Approved by: Michael Johnson <michaeljohnson at ahze.net> (maintainer)
[AutoUpgrade] Upgrade old-style !tbaa.struct field tags (#225967)
Extend the TBAA auto-upgrade to rewrite old-style scalar field tags
inside !tbaa.struct
to the struct-path aware format. bitcode (MetadataLoader) upgraded to
match the existing top-level !tbaa upgrade.
[Instrumentor] Use CreateAllocationSize to compute size of alloca (#226330)
No significant functional change, but the IR might look slightly
different.
[Clang] Enforce the same size limits for `vector_size` and `ext_vector_type` (#226375)
Fixes #165458
A `bool` vector declared with `ext_vector_type` isn't lowered as an LLVM
vector in memory: `ConvertTypeForMem` packs it into a single integer
with one bit per element. `BuildExtVectorType` only checked that the
element count fits in 32 bits, though, so a vector of 187,553,262 bools
got through Sema and the first consumer that needed its memory type (the
zero initializer of a tentative definition here) asked
`IntegerType::get` for far more than the 2^23 bits it supports. The
count matters for every element type, not just `bool`, because Sema also
forms bool vectors out of other vectors (`c ? true : false` with a
`char` vector condition), and `vector_size` was no better off with its
limits of 2^32 elements and 2^61 bytes.
Both attributes now go through the same two limits when the type is
built, reusing the existing "vector size too large" error: at most
`llvm::IntegerType::MAX_INT_BITS` (2^23) elements, and at most 2^28
[2 lines not shown]
[CIR] Fix fp-contract.c checks for -ffp-contract=off and CIR locations
Bound the trailing CIR-OFF-NOT with a CIR-OFF check on nested_pragmas,
where float_control(precise, on) forms a cir.fmuladd even under
-ffp-contract=off. Allow the loc suffix CIR prints after each op in the
end-of-line anchors.
[llvm] produce a more consistent estimates of bit width needed when parsing an integer (#205947)
A colleague of mine noticed that `"12535824225335233"` parses in MLIR's
integer attribute parser as a 68-bit integer, even though it is a 53-bit
constant. I traced this back to `StringRef::consumeInteger`'s heuristic
estimate of the bit size. This change replaces that heuristic with a
default 64-bit storage, doubling the storage as more digits are parsed.
This produces a potentially larger over-estimate of the total storage
required, but does so in a less arbitrary manner and reduces the
over-approximation for numbers close to the 64-bit boundary.
Nb., A first iteration of this change tightened that estimate to at most
a 1-bit overapproximation with a lookup-table.
Assisted by Gemini
[clang-format] Preserve enum initializer continuation indentation (#223435)
Fixes #223011
Enum assignment operators are annotated as TT_EnumEqual so they can be
aligned independently in #194154. However, this means
ContinuationIndenter no longer recognizes a wrapped enum `=` as
TT_BinaryOperator. As a result, it may force unnecessary breaks within
the RHS binary expression.
Co-authored-by: Aaron Saw Min Sern <aaron at aaronsms.com>
