PowerPC: Promote 32-bit ops to 64-bit in place for EXTSW elimination (#229054)
promoteInstr32To64ForElimEXTSW rebuilt a 32-bit instruction as its
64-bit counterpart (e.g. SRAWI -> SRAWI8) with BuildMI, which adds the opcode's
implicit defs, and then copied over the original operands, which already carry them.
This produced duplicate, inconsistent defs:
%8:g8rc = SRAWI8 killed %7, 8, implicit-def $carry, implicit-def dead $carry
The 32-bit and 64-bit opcodes have the same operand layout, so mutate the
original instruction with setDesc instead. This keeps the original implicit defs
with their dead flags, and also preserves the memoperands and MI flags
that rebuilding dropped. The preserved memoperand on a promoted LHA8 allows
the scheduler to reorder it with spills in aix-cc-abi.ll.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[lldb][test] Check cryptography.x509 in the strict test requirements (#229409)
`lldb_find_python_module(cryptography)` only runs `import cryptography`,
which does not load the native `cryptography.hazmat.bindings._rust`. An
install without cffi (`pip install --no-deps cryptography`) passed the
check, then every `from cryptography import x509` in `TestSymStore.py`
failed with `"ModuleNotFoundError: No module named '_cffi_backend'"`.
This patch imports `cryptography.x509` instead so such an install fails
at configure time.
This was uncovered in swiftlang testing.
Targets: Remove redundant TRI arguments from InstrInfo helpers (#228165)
Continue with cleanups enabled by #158224. This is directly available in
TargetInstrInfo.
Co-authored-by: Claude Opus 5 <noreply at anthropic.com>
Unlock zfs resources through typed models
## Problem
Internal callers (failover, boot import, KMIP) started a private dict-based unlock job with its own private models, and results were read with dict indexing. Changing a key from a pipe also rejected valid keys with a leading zero, and change_key accepted keys and passphrases that ZFS would later refuse.
## Solution
- **Unlock**: `zfs.resource.encryption.unlock` gains `toggle_attachments`, and internal callers start the public job with `ZFSResourceEncryptionUnlockArgsData` and read the returned entry by attribute. `unlock_impl` is now the non-job implementation that takes the model and unwraps secrets once; pool.dataset.unlock calls it directly since it already holds the same job lock.
- **Change key**: the key must be 64 hex characters and a passphrase 8 to 512 characters; a key read from the input pipe is matched as hex text instead of round-tripped through int.
- **Cleanup**: shared `secret_value`/`ancestor_chain` and `is_internal_dataset_name` live in one place each, store_key receives the lowercase ZFS key format while hook payloads are uppercase, and the sync_keys failure is logged with its traceback.
[lldb][Windows] Honor the last stdio file action when launching a process (#229435)
lldb starts lldb-server with its stdio first closed and then reopened on
the null device. On Windows, the launcher only looked at the first of
those two actions, so lldb-server inherited lldb's own stdout and
stderr.
lldb-server's messages, like "Connection established." and "lldb-server
exiting...", are buffered and get written when it exits, in the middle
of lldb's output. That makes Shell tests that check lldb's output flaky,
such as `NativePDB/local-variables.cpp`.
The launcher now uses the last action that opens or closes each stdio
descriptor, which is the order the actions are applied in. Duplicating a
descriptor onto another one doesn't change it, so those actions are
skipped.
The new test runs a program through lldb-server and checks that none of
lldb-server's messages show up in lldb's output.
In a stress run of `local-variables.cpp`, failures went from 11 in 640
runs to none.
Create thick zvols with refreservation=auto
libzfs now resolves refreservation=auto in zfs_create() (openzfs/zfs
PR #19227), so a thick volume gets the reservation `zfs create -V`
would set, the volsize plus metadata and raidz/draid overhead, and
libzfs grows it along with the volsize. Default to it at creation
instead of reserving exactly the volsize, accept an explicit 'auto'
the way zfs.resource.set already does, and reject it for a filesystem
with the same error.
Volumes created by earlier releases keep reserving exactly their
volsize until they are grown, which apply_thick_follow() still turns
into auto. The tests compare against a reference `zfs create -V`
volume through a shared helper, and one covers the legacy case.
RuntimeLibcalls: Add provider libraries for targets to reference
Add shared LibcallLibrary defs for targets to reference instead of listing
impls directly: compiler-rt, libm and libc. Define various OS specific library
variants.
ARM, Lanai and SPIRV are migrated to the new organization here. The remaining
targets' SystemRuntimeLibrary bodies are stubbed to (add) and filled in by
pending per-target changes.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
RuntimeLibcallsEmitter: Attribute DefaultCC to the library that references it
Libraries sharing a LibraryName are emitted as one function, so the
DefaultCC for that function was collected from every SystemRuntimeLibrary
that referenced any library with that name. A consumer that references
only a variant not using DefaultCC still contributed its
DefaultLibcallCallingConv, and two such consumers made the name ambiguous.
Only take DefaultCC from consumers whose referenced library uses it. This
is needed once ARM's DefaultCC-using compiler-rt and Lanai's FASTCC both
reference the shared "compiler-rt" name. No change to generated output.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
RuntimeLibcalls: Dedup dispatch calls to the same library function
Referencing a provider both as a base opt-out and as a same-name re-add
variant emitted the same setAvailableLibFuncs_<name> call twice. Collapse
references with the same (Name, FuncSuffix) into one dispatch, and drop
the unused dispatch-side exclusion list.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
RegisterCoalescer: Restore subrange PHI inputs of pruned undef values (#229551)
When joining erases an IMPLICIT_DEF or a copy, the liveness of undefined
lanes may have started at that instruction, so pruneSubRegValues removes
those subrange values. If such a value was live-out into a subrange PHI,
the PHI is left without an input from that predecessor, even though
after the join the lane value from the earlier def of the joined
register reaches it. The main range does not have this gap because
pruneValues collects the pruned end points and joinVirtRegs restores
them with extendToIndices.
Record the PHI kills of the pruned value, the predecessor block ends
where it is live-out into a PHI as in LiveIntervals::hasPHIKill, and
restore them with extendToIndices once operands are rewritten, together
with the existing subrange shrinking. The rewrite is needed so
computeSubRangeUndefs sees the defs of both registers. Only PHI kills
are restored; the in-block kills of a pruned value are reads of an undef
lane and get undef flags instead.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[TySan] Make TySan compatible with sanitizer common interceptors (par… (#197688)
…tial #183310 reland)
Previous attempt here https://github.com/llvm/llvm-project/pull/183310
Some changes already added back here
https://github.com/llvm/llvm-project/pull/192413/changes
This shouldn't cause the same issue on apple platforms that the last
go-around did, and sets TySan up to be able to run on Sanitizer Common
tests and use its features.
(Edit:) Specifically it allows TySan to use all common sanitizer
interceptors, and adds a little more code to help it use the common
sanitizer features to handle deadly signals
[AArch64][SME] Allow more inlining when SME attributes are incompatible. (#223393)
At the moment, 'areInlineCompatible' is very strict as it conservatively
disallows inlining any callee if they use intrinsics and have
incompatible SME attributes. This PR relaxes those constraints by
allowing more intrinsics.
It also updates the Clang diagnostic to match the 'new' behaviour that a
function is no longer inlined despite 'always_inline' when they are not
inline compatible.
This is an alternative approach to #218727. This PR holds on to the
approach of not inlining unless proven safe to do so, as opposed to
relying on the user to know what they're doing (#218727).
This a first step in trying to fix
https://github.com/llvm/llvm-project/issues/217639 in a better way.
AMDGPU: Apply xnack/sramecc settings before constructing TargetLowering
The module flag xnack and sramecc settings were applied to the TargetID
in the GCNSubtarget constructor body, after SITargetLowering was already
constructed in the initializer list. Fix this so future legality rules can
depend on d16PresevesUnusedBits.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
RuntimeLibcallsEmitter: Add isolated LibcallLibrary variant (#223764)
This is essentially a hack to not break the common core functions shared
by most targets. Most targets have essentially the same base set of
compiler-rt or libc/libm functions, but a few are so radically different
there is nothing in common (e.g., the GPU targets have a handful of
functions, arm64ec changes every single function). This bit will pull these out of
the library merge-by-name system, and emitted as its own special case. This
allows the single name to be universal across targets without duplicating large
tables in the emitted inc file.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
Revert "[IndirectBrExpand] Preserve profile weights" (#229691)
Reverts llvm/llvm-project#227784
Causes compile-time regression at `-O0` due to the extra passes.
aarch64: fix HPFAR_EL2_FIPA defines for various configurations
HPFAR_EL2_FIPA is 36bits long when FEAT_D128 and FEAT_LPA aren't
implemented, i.e. HPFAR_EL2[39:4]
Add HPFAR_EL2_FIPA_LPA for when FEAT_D128 is not implemented and
FEAT_LPA is.
Provide HPFAR_EL2_FIPA_{D128_,LPA_,}BITS for the Faulting Intermediate
Physical Address.
Remove HPFAR_EL2_FIPA_BITSHIFT
Fix interface.nic_attach_users crash when VMs or containers exist
## Problem
`nic_attach_users`, added in 4fb2e51a1b, reads `vm.query` and `container.query` results as dicts. Both are typesafe services on master, so internal calls return Pydantic models and subscripting them raised a `TypeError`. As soon as any VM or container existed, `interface.bridge_members_choices` failed, and so did creating or updating a bridge with `bridge_members`.
## Solution
Read the typed `VMEntry` / `ContainerEntry` devices and match `VMNICDevice` / `ContainerNICDevice` attributes instead of subscripting dicts.
`nic_attach_users` only needs persisted NIC config, but both query methods always gathered runtime `status` from libvirt (which can even start libvirtd). Status is now optional: it is skipped when `query-options.extra.retrieve_status` is false (status is then `null`) or when `select` does not include `status`. The default is unchanged, so existing callers, events and the UI still get status.
The value is stored in `status_or_null` (aliased to `status`, so the API schema and payloads are unchanged), and a `status` property returns it non-optional, raising `ValueError` if it was not retrieved. That keeps existing consumers reading `.status` untouched. The update paths exclude `status_or_null` when dumping, since pydantic `exclude` matches field names rather than aliases.
Revert "interfaces: fallback here to prevent php warnings"
This reverts commit cda3b2f717fce26add61c147d1da0b0a0812c3eb.
these are stored by default now after save
