[LLVM][NVPTX][MLIR] Support layouts in mbarrier.init and add mbarrier.check_layout (#217252)
This commit adds LLVM NVPTX and MLIR NVVM support for the mbarrier layout extensions:
- llvm.nvvm.mbarrier.init with trailing immarg `layout` operand, and nvvm.mbarrier.init a matching `layout` attribute (default to 0) Layout 0 is the default in-memory layout and is emitted as a plain mbarrier.init; layout 1 is emitted as mbarrier.init.layout::v1.
- llvm.nvvm.mbarrier.check_layout / nvvm.mbarrier.check_layout, lowering to mbarrier.check_layout.layout::v{0,1}.
Only the layout::v1 form of mbarrier.init and mbarrier.check_layout require PTX ISA 9.3 and sm_90
llvm.nvvm.mbarrier.init{.shared } are also merged into a pointer-overloaded llvm.nvvm.mbarrier.init with calls to either older forms auto-upgraded
Please refer [PTX ISA](https://docs.nvidia.com/cuda/developer-preview/13.4/parallel-thread-execution/index.html)
for more details
Assisted by: Claude Code (Opus 5)
[clangd] Enable query-based custom checks (#216336)
Enable query-based custom checks in clangd behind a new `Diagnostics.ClangTidy.ExperimentalCustomChecks` configuration option.
Custom checks are registered from the per-file clang-tidy options and remain subject to clangd's `FastCheckFilter` policy.
Fixes #206696
Assisted by GPT-5.6
[BOLT][ICP] Use PC-relative instructions for x86 PIC binaries in ICP (#216587)
Currently, BOLT x86 ICP optimization inserts an immediate-to-register
comparison instruction, which forces the use of 32-bit signed (32S)
relocations due to ABI limitations. This behavior does not align well
with the conventions of PIC/PIE binaries and **makes it highly prone to
JITLink relocation overflow errors when dealing with large binaries.**
Therefore, this patch introduces an additional lea instruction for the
x86 architecture to leverage PC-relative (32PC) addressing. This change
is intended to apply by default to PIC binaries, or when specific
options are provided.
Mock VM and container queries in bridge validation unit tests
## Problem
The two bridge unit tests in `test_interface.py` fail with `KeyError: 'vm.query'`. BRIDGE validation now calls `nic_attach_users()` whenever `bridge_members` is set, which queries VMs and containers to find NICs attached directly to a member, but the mock middleware in those tests only stubs `interface.query`, `datastore.query` and `network.common.check_failover_disabled`.
## Solution
Stub `vm.query` and `container.query` with empty results in both tests, so validation reaches the member checks the tests actually assert on.
Revert "[clang] Revert "Disable Unique Internal Linkage Names for internal global vars." (#219261)" (#222486)
This reverts commit 9abbc9183d2231c2e44198100a6cd22ef66e2eb8.
Will reland with a proper fix of the GNU AsmLabelAttr
Co-authored-by: Sharon Xu <sharonxu at fb.com>
acpi_pci: Honor device proximity for DMA tags
A PCI function with its own _PXM still inherits a DMA tag carrying
the upstream bridge's proximity domain. Resolving an SR-IOV VF's
locality through its PF therefore does not affect the domain used for
DMA allocations.
Create and cache a private child tag when the function, or a VF's
owning PF, has an explicit _PXM. Parent it to the existing PCI or IOMMU
tag so its constraints remain intact, then apply the function's domain
without mutating a shared tag.
pci_get_dma_tag() already performs the IOMMU lookup, so remove the
duplicated lookup in the ACPI subclass while here.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59063
(cherry picked from commit f1f58bdf7b5fc58e6011c6ac2ae2ba129dc41991)
[FLANG][OpenMP] Handling pure directives in DO CONCURRENT (#216642)
A directive with the PURE property is allowed inside a DO CONCURRENT
construct starting with OpenMP 6.0.
acpi_pci: Cache PCI proximity domains
A PCI function's _PXM is stable for the lifetime of its device
instance, but CPU and DMA locality queries may evaluate it repeatedly.
SR-IOV amplifies this because every VF resolves locality through the
same PF.
Cache successful mappings and the stable absence of _PXM on the
locality source device, and share that result between CPU and domain
queries. Continue to retry generic evaluation or mapping errors rather
than making a potentially transient failure permanent.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59207
(cherry picked from commit 5f78d024695b39208a6c92f6a96017bae53cdf2c)
acpi_pci: Preserve CPU locality queries for descendants
bus_generic_get_cpus() preserves the original leaf device while
forwarding a request through the bus hierarchy. Consequently,
acpi_pci_get_cpus() may receive a descendant below a PCI function
rather than one of the PCI bus's direct children.
Only apply the SR-IOV PF-locality mapping to direct PCI children.
Preserve the previous ACPI CPU-locality lookup for descendants so their
unrelated bus ivars are not interpreted as PCI device information.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59206
(cherry picked from commit dc4f80da18f0dcc557a969b4283a86569266eb5c)
acpi_pci: Inherit PF locality for SR-IOV VFs
SR-IOV VFs are instantiated from their PF and intentionally do not
receive an ACPI handle by matching their runtime BDF. Consequently,
ACPI locality queries for a VF fall back to the upstream bus. This is
usually sufficient, but loses a _PXM supplied specifically for the PF.
Use the PCI core's owning-PF accessor for BUS_GET_DOMAIN and
BUS_GET_CPUS requests made for a VF. This preserves the VF's lack of
an ACPI handle while allowing its CPU and NUMA placement to follow the
PF.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59062
(cherry picked from commit 1a2a88684a0126be8d7172362d5ec7dbb7a41c81)
acpi_pci: Do not match SR-IOV VFs to ACPI devices
SR-IOV VFs are instantiated dynamically from their PF rather than
enumerated from ACPI. A VF's runtime slot and function can match an
unrelated _ADR below the bridge. acpi_pci_save_handle() stores that
handle in the VF's devinfo before acpi_pci_update_device() runs.
If the handle is already bound to another device_t whose parent is not
acpi0, acpi_pci_update_device() panics under INVARIANTS. Without
INVARIANTS, the VF retains the unrelated handle, so subsequent ACPI
lookups, including NUMA and power-management operations, can act on the
wrong namespace node.
Skip ACPI namespace matching for VFs.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59061
(cherry picked from commit 8b74806161a188103666387013cdd93fb3f5dc07)
Rework snapshot rollback with batched destroys
## Problem
Rolling back past a snapshot that has a dependent clone crashed: the "no safety check" path called a `destroy()` method that does not exist on the pylibzfs dataset object, and the "newer clone" path skipped the safety check and let the kernel refuse with a raw EEXIST after some newer snapshots were already destroyed one at a time. With `recursive_rollback`, a blocked child was only discovered after the parent had already been rolled back, and every kernel error was flattened into `ValidationError(EINVAL)` with a raw strerror.
## Solution
- **Enumerate once, up front, for the whole tree.** Newer snapshots are collected for every affected dataset before anything is touched. Without `recursive`, the rollback is refused with every conflicting snapshot named; with it, holds and clones are checked first and the rollback is refused before any destroy, naming each blocker. A missing child snapshot fails the whole tree before the parent moves.
- **Destroy the newer snapshots in one ioctl per dataset**, so the kernel either destroys all of them or none, and a failure names the snapshots from the kernel's own error list.
- **Clones are always unmounted before being destroyed** - `force` only selects how forcefully - and destroyed via `destroy_resource()`.
- **Error model.** Input problems (bad path, missing snapshot, newer snapshots without a destroy flag) stay `ValidationError`; blockers and operational failures surface as `CallError` with the kernel's errno. A newer bookmark still fails the rollback with EEXIST, since bookmarks are not managed here; the error says so and names the manual remedy.
[AMDGPU] Drop the redundant operand register-class verifier check
The generic MachineVerifier already rejects a register operand whose
class does not fit the instruction's operand class, for both virtual
(hasSuperClassEq / getMatchingSuperRegClass) and physical (contains)
registers, using the HwMode-resolved operand class. On subtargets that
require aligned VGPRs that class is the even-aligned one, so the generic
check catches a misaligned tuple on its own.
Remove SIInstrInfo::verifyInstruction's own alignment and physical
register-class checks and the now-unused getUnalignedEquivalentRC helper.
Misaligned tuples now report the generic "Illegal virtual/physical
register for instruction" instead of "Subtarget requires even aligned
vector registers"; a bad physical class reports the same instead of
"Operand has incorrect register class".
[AMDGPU] Match the AsmParser's operand-side check and share its helper
In the upcoming PR AsmParser performs the same alignment check but differently:
it tests whether a concrete physreg, which carries no regclass, is in the
relaxed operand's regclass.
Change the verifier to work the same way, reusing
AMDGPUBaseInfo::getUnalignedEquivalentRC.
Co-Authored-By: Claude <noreply at anthropic.com>
[AMDGPU] Verify VGPR tuple alignment from the operand register class
The machine verifier decided VGPR tuple alignment with isProperlyAlignedRC(),
which inspects only the register's own class. Alignment is not really a property
of the register in isolation: whether a 64-bit tuple must be even-aligned depends
on the operand it feeds, and on mixed-alignment targets the same register class
can be required to be aligned in one operand and exempt in another. Inspecting
only the register also conflates alignment with unrelated problems - a register
that is simply the wrong bank or size for the operand came out as "requires even
aligned vector registers" as well.
Make the operand's register class the source of truth instead: a register is
misaligned only when it does not satisfy the operand's class but its even-aligned
same-bank/width equivalent (SIRegisterInfo::getAlignedEquivalentRC) would. A
register that fits neither is a genuine class or bank mismatch and is left to the
illegal-register and sub-register checks. So an AGPR in a VGPR|SGPR (VS_64)
operand is now reported as an illegal register, and a wrong-size register (e.g. a
64-bit VGPR in a 128-bit MFMA source) or an invalid sub-register index is
reported by those checks alone, no longer doubled up as an "even aligned" error.
[17 lines not shown]
[LLVM][Maintainers] Add myself as NVPTX backend co-maintainer (#215627)
I've been contributing to the NVPTX backend (TableGen, ISel lowering)
and would also like to help maintain it going forward.
Signed-off-by: Durgadoss R <durgadossr at nvidia.com>
[AMDGPU] Drop the redundant operand register-class verifier check
The generic MachineVerifier already rejects a register operand whose
class does not fit the instruction's operand class, for both virtual
(hasSuperClassEq / getMatchingSuperRegClass) and physical (contains)
registers, using the HwMode-resolved operand class. On subtargets that
require aligned VGPRs that class is the even-aligned one, so the generic
check catches a misaligned tuple on its own.
Remove SIInstrInfo::verifyInstruction's own alignment and physical
register-class checks and the now-unused getUnalignedEquivalentRC helper.
Misaligned tuples now report the generic "Illegal virtual/physical
register for instruction" instead of "Subtarget requires even aligned
vector registers"; a bad physical class reports the same instead of
"Operand has incorrect register class".
[AMDGPU] Match the AsmParser's operand-side check and share its helper
In the upcoming PR AsmParser performs the same alignment check but differently:
it tests whether a concrete physreg, which carries no regclass, is in the
relaxed operand's regclass.
Change the verifier to work the same way, reusing
AMDGPUBaseInfo::getUnalignedEquivalentRC.
Co-Authored-By: Claude <noreply at anthropic.com>
[AMDGPU] Verify VGPR tuple alignment from the operand register class
The machine verifier decided VGPR tuple alignment with isProperlyAlignedRC(),
which inspects only the register's own class. Alignment is not really a property
of the register in isolation: whether a 64-bit tuple must be even-aligned depends
on the operand it feeds, and on mixed-alignment targets the same register class
can be required to be aligned in one operand and exempt in another. Inspecting
only the register also conflates alignment with unrelated problems - a register
that is simply the wrong bank or size for the operand came out as "requires even
aligned vector registers" as well.
Make the operand's register class the source of truth instead: a register is
misaligned only when it does not satisfy the operand's class but its even-aligned
same-bank/width equivalent (SIRegisterInfo::getAlignedEquivalentRC) would. A
register that fits neither is a genuine class or bank mismatch and is left to the
illegal-register and sub-register checks. So an AGPR in a VGPR|SGPR (VS_64)
operand is now reported as an illegal register, and a wrong-size register (e.g. a
64-bit VGPR in a 128-bit MFMA source) or an invalid sub-register index is
reported by those checks alone, no longer doubled up as an "even aligned" error.
[17 lines not shown]
[AMDGPU] Restructure VGPR-alignment verifier tests, NFC (#219229)
Rewrite verify-gfx90a-aligned-vgprs.mir and verify-ds-gws-align.mir so each case
documents inline what makes it invalid, and match the verifier's fuller output -
the "*** Bad machine code ***" kind and the "- instruction:" line - instead of a
single message fragment. Pure test restructure with no functional change, so the
follow-up commit that derives alignment from the operand register class shows
only the change in diagnostic wording.
Co-Authored-By: Claude <noreply at anthropic.com>
[AMDGPU] Gate 64-bit VGPR copy lowering on operand register class in copyPhysReg (#219562)
copyPhysReg lowers a 64-bit VGPR copy to V_MOV_B64_e32 / V_PK_MOV_B32
when available. Emit the wide move only when the destination and source
are members of the move's HwMode-resolved operand classes; otherwise
fall through to the element-wise V_MOV_B32 expansion, to respect
alignment requirements.
Co-authored-by: Claude <noreply at anthropic.com>
NAS-141987 / 27.0.0-BETA.1 / Rework snapshot rollback with batched destroys (#19518)
## Problem
Rolling back past a snapshot that has a dependent clone crashed: the "no
safety check" path called a `destroy()` method that does not exist on
the pylibzfs dataset object, and the "newer clone" path skipped the
safety check and let the kernel refuse with a raw EEXIST after some
newer snapshots were already destroyed one at a time. With
`recursive_rollback`, a blocked child was only discovered after the
parent had already been rolled back, and every kernel error was
flattened into `ValidationError(EINVAL)` with a raw strerror.
## Solution
- **Enumerate once, up front, for the whole tree.** Newer snapshots are
collected for every affected dataset before anything is touched. Without
`recursive`, the rollback is refused with every conflicting snapshot
named; with it, holds and clones are checked first and the rollback is
refused before any destroy, naming each blocker. A missing child
snapshot fails the whole tree before the parent moves.
[9 lines not shown]
NAS-143037 / 27.0.0-BETA.1 / Log full git output to its own log file (#19667)
## Problem
`utils/git.py` shortened git's stderr to 50 characters before putting it
into the `CallError`, and `textwrap.shorten` collapses newlines before
it truncates. `git clone` always opens stderr with `Cloning into
'/mnt/.ix-apps/truenas_catalog'...`, which is 47 characters by itself,
so every clone failure produced the byte-identical message and the
`fatal:` line saying what actually went wrong was discarded every time.
Bad credentials, DNS, TLS, a proxy and a missing branch were
indistinguishable in the UI, in the logs and in a debug bundle, and
git's stderr was preserved nowhere else.
## Solution
- **A dedicated `git` log file.** The tail of git's output goes to
`/var/log/git.log` rather than back into `middlewared.log`, which is
what the original shortening was trying to keep clean. The syslog-ng
filter and destination generate themselves from `ALL_LOG_FILES`, so
`logger.py` is the only place that needed touching, plus a line in the
[12 lines not shown]
Stop passing middlewared's environment to init/shutdown scripts
## Problem
User scripts were spawned with middlewared's entire environment, including `NOTIFY_SOCKET`. Since our unit sets `NotifyAccess=all`, a daemon a script leaves behind can send `MAINPID=` and be adopted as the unit's main process, so systemd tears middlewared down when that daemon later exits. A user hit this with a POSTINIT script starting a NUT driver: the driver was killed as a duplicate on every boot, middlewared went down with it, and Apps never started.
## Solution
Pass a curated set of names instead of inheriting: `PATH`, `TZ`, `LANG`, `USER`, the proxy variables and `REQUESTS_CA_BUNDLE`, all of which existing scripts may reasonably depend on. Allowlisted rather than denylisted so that whatever systemd or a plugin sets next stays out of user scripts too.
