[CodeGen] Remove unused IntrinsicLowering::LowerToByteSwap (NFC) (#230010)
The last use was removed on September 4, 2025 in commit
3f757a39f2855cd06c62a85b8e27fd56fa017e78.
Assisted-by: Antigravity
[NFC][AutoUpgrade] Add logging for module flags upgrade (#226165)
Logging is useful to see how a module changes as it goes through
auto-upgrade. It also makes it easier to understand tests.
Note that tests that involve logging are only active for LLVM builds
with assertions.
For now, only changes in branch protection attributes are logged.
net/amqpcat: Update to 1.1.1
- bump amq-protocol.cr dependency to 1.3.1 for Crystal 1.21
- drop upstreamed IO::Memory writable patch
- report the correct version in tarball builds
Changelog: https://github.com/cloudamqp/amqpcat/releases/tag/v1.1.1
Sponsored by: SkunkWerks, GmbH
devel/git-cola: Update to 4.19.0
- Git DAG gains an inline graph viewer in the commit list
- reloads externally edited commit messages on refresh
Changelog: https://github.com/git-cola/git-cola/blob/main/CHANGES.rst#v4190
Reported by: portscout
Sponsored by: SkunkWerks, GmbH
devel/buildkite-cli: Update to 3.59.1
- version variable moved from internal/version to cmd/version,
adjust ldflags so `bk version` reports the port version
Changelog: https://github.com/buildkite/cli/releases/tag/v3.59.1
Sponsored by: SkunkWerks, GmbH
devel/buildkite-agent: Update to 3.138.0
- graceful agent shutdown reporting and systemd watchdog support
- upstream expects this to be the last v3 feature release
Changelog: https://github.com/buildkite/agent/releases/tag/v3.138.0
Sponsored by: SkunkWerks, GmbH
[TargetLowering][X86] Prefer 'r' over 'm' for foldable "rm" inline asm operands
An "rm" (register-or-memory) inline asm operand has always resolved to
'm', because getConstraintPreferences() picks the most general
constraint present, and 'm' is more general than 'r'. That's safe, since
memory can't run out, but it forces a value that could stay in a
register through a stack slot even when there's no register pressure
(https://github.com/llvm/llvm-project/issues/20571).
Prefer 'r' instead where the register allocator can fold the register
back to a stack slot when it runs out of registers, and mark the
register operand foldable (InlineAsm::Flag::setRegMayBeFolded()) so it
does. Both allocators can: the greedy allocator folds an operand when it
spills its value, and the fast allocator folds operands up front when
the asm's register operands wouldn't fit.
ParseConstraints() sets AsmOperandInfo::MayFoldRegister for an operand
whose constraint codes are exactly {r, m}, above -O0, on a target that
opts in through the new supportsRegMemInlineAsmFolding() hook, which
[20 lines not shown]
[CodeGen] Report an error for a direct inline asm output in memory
An inline asm output returned by value has no memory to write to, yet a
constraint such as "=rm" picks memory, the most general constraint, as
does "=m". SelectionDAG asserted on that ("Can only indirectify direct
input operands!"), and GlobalISel dereferenced a null pointer. Clang
never emits such an output, since it passes the address of a memory
output, but other IR can. Report "cannot handle direct memory outputs
yet for constraint 'm'" instead, like the other inline asm errors there.
Assisted-by: Claude Opus 5.5
[RegAllocFast] Fold foldable inline asm operands under register pressure
An inline asm register operand marked foldable (from an "rm" constraint)
may be replaced with a stack slot when the register allocator runs out
of registers. The greedy allocator does that when it spills the value.
The fast allocator can't: it assigns the operands of an instruction one
at a time, and folding replaces the instruction. So it reported
"inline assembly requires more registers than available" instead.
Before allocating a block, estimate from each inline asm's own operands
whether they fit in registers, and fold as many foldable registers as
needed to make them fit, so the common case without pressure still gets
a register. Values that only live across the asm don't count, since the
allocator spills them when it needs their registers. The estimate
follows allocateInstruction():
- First all defs get distinct registers, avoiding physreg defs; then all
uses, along with the defs still occupied while the uses are read
(early-clobber and tied defs, see isLiveThroughDef()), get distinct
[26 lines not shown]
[TargetInstrInfo] Fix folding inline asm operands next to tied operands
foldInlineAsmMemOperand() swapped a register operand for the target's
memory operands with MachineInstr::removeOperand(), which asserts when a
later operand is tied, because moving it would break the tie. Inline asm
lists every input after every output, so folding any operand that comes
before another tied pair asserted, e.g. an "rm" input followed by the
input of a "+r" operand, or one of two "+rm" operands. Without
assertions, the moved operands kept stale tie indices. Untie the
operands, rebuild the operand list, and re-tie the remaining pairs at
their new positions.
It also gave up when the register appears in more than one operand, e.g.
one value passed to two "rm" operands, which left the greedy allocator
unable to spill that value at all. Fold every such operand into the
stack slot.
Finally, take MayLoad from the folded operands rather than from every
read of the register: a folded def whose tied use is another virtual
[9 lines not shown]
AMDGPU: Stop relying on -amdgpu-scalarize-global-loads=false in more tests
Convert operation tests to functions taking their inputs as arguments,
and index loads by workitem id in kernels where the stores matter.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Keep zettarepl's encrypted record call working on targets
## Problem
Replication sources call `pool.dataset.insert_or_update_encrypted_record` over midclt on the target to store the target dataset's key. That private method was removed when encryption moved to `zfs.resource.encryption`, so replicating to a target on this version would fail after the stream was received and leave the encrypted dataset without a stored key, meaning it would not unlock on reboot.
## Solution
Restored the private method on `pool.dataset` with its original payload, forwarding to `zfs.resource.encryption.store_key`. Also trimmed encryption docstrings that repeated the API model field descriptions and corrected which supplied keys get stored on unlock.
[TargetLowering][X86] Prefer 'r' over 'm' for foldable "rm" inline asm operands
An "rm" (register-or-memory) inline asm operand has always resolved to
'm', because getConstraintPreferences() picks the most general
constraint present, and 'm' is more general than 'r'. That's safe, since
memory can't run out, but it forces a value that could stay in a
register through a stack slot even when there's no register pressure
(https://github.com/llvm/llvm-project/issues/20571).
Prefer 'r' instead where the register allocator can fold the register
back to a stack slot when it runs out of registers, and mark the
register operand foldable (InlineAsm::Flag::setRegMayBeFolded()) so it
does. Both allocators can: the greedy allocator folds an operand when it
spills its value, and the fast allocator folds operands up front when
the asm's register operands wouldn't fit.
ParseConstraints() sets AsmOperandInfo::MayFoldRegister for an operand
whose constraint codes are exactly {r, m}, above -O0, on a target that
opts in through the new supportsRegMemInlineAsmFolding() hook, which
[20 lines not shown]
[CodeGen] Report an error for a direct inline asm output in memory
An inline asm output returned by value has no memory to write to, yet a
constraint such as "=rm" picks memory, the most general constraint, as
does "=m". SelectionDAG asserted on that ("Can only indirectify direct
input operands!"), and GlobalISel dereferenced a null pointer. Clang
never emits such an output, since it passes the address of a memory
output, but other IR can. Report "cannot handle direct memory outputs
yet for constraint 'm'" instead, like the other inline asm errors there.
Assisted-by: Claude Opus 5.5
[RegAllocFast] Fold foldable inline asm operands under register pressure
An inline asm register operand marked foldable (from an "rm" constraint)
may be replaced with a stack slot when the register allocator runs out
of registers. The greedy allocator does that when it spills the value.
The fast allocator can't: it assigns the operands of an instruction one
at a time, and folding replaces the instruction. So it reported
"inline assembly requires more registers than available" instead.
Before allocating a block, estimate from each inline asm's own operands
whether they fit in registers, and fold as many foldable registers as
needed to make them fit, so the common case without pressure still gets
a register. Values that only live across the asm don't count, since the
allocator spills them when it needs their registers. The estimate
follows allocateInstruction():
- First all defs get distinct registers, avoiding physreg defs; then all
uses, along with the defs still occupied while the uses are read
(early-clobber and tied defs, see isLiveThroughDef()), get distinct
[26 lines not shown]
[TargetInstrInfo] Fix folding inline asm operands next to tied operands
foldInlineAsmMemOperand() swapped a register operand for the target's
memory operands with MachineInstr::removeOperand(), which asserts when a
later operand is tied, because moving it would break the tie. Inline asm
lists every input after every output, so folding any operand that comes
before another tied pair asserted, e.g. an "rm" input followed by the
input of a "+r" operand, or one of two "+rm" operands. Without
assertions, the moved operands kept stale tie indices. Untie the
operands, rebuild the operand list, and re-tie the remaining pairs at
their new positions.
It also gave up when the register appears in more than one operand, e.g.
one value passed to two "rm" operands, which left the greedy allocator
unable to spill that value at all. Fold every such operand into the
stack slot.
Finally, take MayLoad from the folded operands rather than from every
read of the register: a folded def whose tied use is another virtual
[9 lines not shown]
AMDGPU: Avoid null and poison pointers in call-argument-types
Cleanup these tests to avoid unnecessarily depending on undefined behavior
and -amdgpu-scalarize-global-loads=0.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[CodeGen] Report an error for a direct inline asm output in memory
An inline asm output returned by value has no memory to write to, yet a
constraint such as "=rm" picks memory, the most general constraint, as
does "=m". SelectionDAG asserted on that ("Can only indirectify direct
input operands!"), and GlobalISel dereferenced a null pointer. Clang
never emits such an output, since it passes the address of a memory
output, but other IR can. Report "cannot handle direct memory outputs
yet for constraint 'm'" instead, like the other inline asm errors there.
Assisted-by: Claude Opus 5.5
[TargetInstrInfo] Fix folding inline asm operands next to tied operands
foldInlineAsmMemOperand() swapped a register operand for the target's
memory operands with MachineInstr::removeOperand(), which asserts when a
later operand is tied, because moving it would break the tie. Inline asm
lists every input after every output, so folding any operand that comes
before another tied pair asserted, e.g. an "rm" input followed by the
input of a "+r" operand, or one of two "+rm" operands. Without
assertions, the moved operands kept stale tie indices. Untie the
operands, rebuild the operand list, and re-tie the remaining pairs at
their new positions.
It also gave up when the register appears in more than one operand, e.g.
one value passed to two "rm" operands, which left the greedy allocator
unable to spill that value at all. Fold every such operand into the
stack slot.
Finally, take MayLoad from the folded operands rather than from every
read of the register: a folded def whose tied use is another virtual
[8 lines not shown]
[TargetInstrInfo] Add C inline asm statements to greedy-inline-asm-fold.mir
Show the C source behind each test so it's clear which MIR operand
corresponds to which asm constraint. Also reword the first test's
comment per review.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[TargetInstrInfo] Untie inline asm operands while collecting ties
Use MachineInstr::isRegTiedToDefOperand to find the tied uses, and
untie each one as it's found. Untying a use also unties its def, so
the separate untie loop isn't needed.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>