[Lifetime Safety] Name operator calls in alias-chain diagnostics (#221803)
This updates Lifetime Safety alias-chain diagnostics to identify
overloaded operator and conversion calls instead of describing them
generically as an `expression`.
Previously, these calls were reported as `expression aliases the storage
of ...`, which could make it unclear which operation introduced the
alias. The diagnostic now reports the callee using the existing
diagnostic name printer, producing descriptions such as:
- `result of call to 'operator->'`
- `result of call to 'operator()'`
- `result of call to 'operator basic_string_view'`
Template arguments are preserved for operator function-template
specializations. For example:
- `result of call to 'operator+<const int>'`
[6 lines not shown]
[AArch64][GlobalISel] Lower vector overflow intrinsics (#222091)
As we have no native support for vector version of these intrinsics they
should be lowered.
[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)
[AMDGPU] Make custom AsmParser matchers alignment aware
Currently custom matchers accept registers belonging to unaligned classes,
leaving the alignment check and its diagnostic to validateVGPRAlign. The problem
is that validateVGPRAlign does not account for the operand register class, which
may have a different alignment requirement on mixed-alignment targets.
The fix is to make a custom matcher resolve the operand's _AlignTarget class via
HwMode and use that resolved class to accept a register. However, doing so alone
would reject a misaligned register with a generic "invalid operand for
instruction" diagnostic, so extra infrastructure conveys the alignment diagnostic
instead: on a class miss, diagnoseRegAlign re-checks the register against the same
class with alignment relaxed (getUnalignedEquivalentRC, new in AMDGPUBaseInfo);
if it fits, the only problem is alignment, so it records
OperandMatchError::VGPRAlignMismatch on the operand. matchAndEmitInstruction
selects that reason and prints the alignment error, now at the offending operand
column instead of column 1.
This commit converts the input-mods and DP-ALU DPP matchers. The no-modifier
[4 lines not shown]
[AMDGPU] Rename the alignment-aware operand predicates to *Target, NFC
The predicates take a *_AlignTarget/_Target operand, so name them after
it. The HwMode resolution behind the operand's class is an implementation
detail that need not appear in the name.
[AMDGPU] Route no-modifier reg-or-inline AsmParser operands through HwMode predicate
Convert the reg-or-inline operands with no modifiers (MFMA VGPR/AGPR
sources, VCSrc, v_pk_mov_b32, VOP scalar f64) from the fixed-class
isRegOrInlineNoMods to the HwMode-aware isRegOrInlineNoModsByHwMode, so an
odd-aligned tuple is rejected at the offending operand column instead of by
the validateVGPRAlign catch-all.
Co-Authored-By: Claude <noreply at anthropic.com>
[AMDGPU] Drop the misaligned VGPR-tuple AsmParser diagnostic
The alignment-aware matchers already reject a misaligned tuple, so a
misaligned operand now fails as a plain invalid operand. Keeping the
dedicated "vgpr tuples must be 64 bit aligned" message only for that
case is not worth the extra match-error ranking, the per-operand
diagnostic, and getUnalignedEquivalentRC, so remove all of it.
[AMDGPU] Update no-modifier operand tests for the dropped align diagnostic
The no-modifier reg-or-inline operands routed through the HwMode
predicate now report a misaligned tuple as a plain invalid operand,
matching the diagnostic dropped earlier in the stack.
[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)
