LLVM/project 1d7a2c9 — llvm/include/llvm/CodeGen SlotIndexes.h, llvm/lib/CodeGen RegAllocGreedy.cpp LiveIntervals.cpp

[CodeGen] Drop dead SlotIndexes before allocation

SlotIndexes keeps the index list entry of an erased instruction and only
clears its instruction pointer. Live range sizes are measured in slot
indexes and greedy ranks ranges by size, so the leftovers inflate some
ranges more than others and reorder allocation, spilling heavily on
register-starved functions.

Add SlotIndexes::compactIndexes() to erase them. Erased entries are
unlinked, so holding an index to one is now a bug; linkedEntry() asserts
on it. The one analysis that did was LiveIntervals, so add
removeUnreferencedIntervals() to retire the intervals responsible.

Off by default behind -greedy-compact-slot-indexes, since it changes
allocation across much of the test suite.
DeltaFile
+288-0llvm/unittests/CodeGen/SlotIndexesTest.cpp
+43-0llvm/lib/CodeGen/SlotIndexes.cpp
+32-0llvm/test/CodeGen/AMDGPU/greedy-compact-slot-indexes.ll
+23-6llvm/include/llvm/CodeGen/SlotIndexes.h
+17-0llvm/lib/CodeGen/LiveIntervals.cpp
+12-1llvm/lib/CodeGen/RegAllocGreedy.cpp
+415-71 files not shown
+419-77 files

HardenedBSD/ports a61c7c9 — devel/llvm18 pkg-plist, devel/py-qcs-api-client-common Makefile distinfo

Merge branch 'freebsd/main' into hardenedbsd/main
DeltaFile
+1,059-0devel/py-qcs-api-client-common/distinfo
+0-929science/py-pymol/pkg-plist
+523-371devel/py-qcs-sdk-python/distinfo
+0-571devel/llvm18/pkg-plist
+567-0devel/py-qcs-api-client-common/Makefile
+494-0x11-wm/bvwm/pkg-plist
+2,643-1,871118 files not shown
+3,684-2,780124 files

OpenZFS/src a4d408b — .github/workflows zfs-arm.yml

CI: run only the dependency part of qemu-3-deps-vm.sh in zfs-arm

zfs-arm runs qemu-3-deps-vm.sh on the ARM runner itself, without
ONLY_DEPS. Its Ubuntu branch therefore still installs
linux-modules-extra-$(uname -r), and ARM runners on image 20261018.154.1
boot 7.0.0-1017-azure, which has no such package.  apt-get fails and the
job fails in "Install dependencies".

zfs-arm needs only the dependencies. After them the script prepares a
test VM: it enables NFS, Samba and the guest agent, rewrites the GRUB
command line and resets cloud-init. zfs-arm then only builds, loads the
zfs.ko it built and creates a pool on a file. Set ONLY_DEPS=1, as the
other workflows that run the script on the runner do.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Alexander Moch <mail at alexmoch.com>
Closes #19502
DeltaFile
+1-1.github/workflows/zfs-arm.yml
+1-11 files

LLVM/project 5d49ab6 — clang/test/CodeGen ms-intrinsics-other.c ms-intrinsics.c, llvm/lib/Transforms/InstCombine InstCombineAtomicRMW.cpp

[InstCombine] Canonicalize atomicrmw sub of a constant to add (#232626)

Rewrite `atomicrmw sub ptr, C` as `atomicrmw add ptr, -C`. This
matches the canonical form InstCombine already uses for plain `sub`.
In wrapping arithmetic $old - C = old + (-C)$, so both the stored
value and the returned old value stay the same, including when C is
`INT_MIN`. Ordering, syncscope and metadata are kept.

```llvm
; before
%old = atomicrmw sub ptr %p, i32 1 syncscope("agent") monotonic
; after
%old = atomicrmw add ptr %p, i32 -1 syncscope("agent") monotonic
```
This benefits AMDGPU, for example: https://godbolt.org/z/fa9n1rPfq
DeltaFile
+12-12clang/test/CodeGen/ms-intrinsics.c
+5-5llvm/test/Transforms/InstCombine/atomicrmw-add-neg.ll
+4-4clang/test/CodeGen/ms-intrinsics-other.c
+8-0llvm/lib/Transforms/InstCombine/InstCombineAtomicRMW.cpp
+29-214 files

HardenedBSD/ports 793dd0c — misc Makefile, misc/ttfx pkg-descr Makefile.crates

misc/ttfx: New port: Terminal text effects, a Rust port of terminaltexteffects

ttfx renders terminal text effects (decrypt, beams, matrix, and many
more) from text piped on standard input. It is a Rust port of
TerminalTextEffects (TTE) shipped as a single binary with no runtime
dependencies.

WWW: https://github.com/omacom/ttfx

Reported by:    jkh (new maintainer)
Pull Request:   https://github.com/freebsd/freebsd-ports/pull/630
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
DeltaFile
+59-0misc/ttfx/distinfo
+29-0misc/ttfx/Makefile
+28-0misc/ttfx/Makefile.crates
+3-0misc/ttfx/pkg-descr
+1-0misc/Makefile
+120-05 files

FreeBSD/ports 793dd0c — misc Makefile, misc/ttfx pkg-descr Makefile.crates

misc/ttfx: New port: Terminal text effects, a Rust port of terminaltexteffects

ttfx renders terminal text effects (decrypt, beams, matrix, and many
more) from text piped on standard input. It is a Rust port of
TerminalTextEffects (TTE) shipped as a single binary with no runtime
dependencies.

WWW: https://github.com/omacom/ttfx

Reported by:    jkh (new maintainer)
Pull Request:   https://github.com/freebsd/freebsd-ports/pull/630
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
DeltaFile
+59-0misc/ttfx/distinfo
+29-0misc/ttfx/Makefile
+28-0misc/ttfx/Makefile.crates
+3-0misc/ttfx/pkg-descr
+1-0misc/Makefile
+120-05 files

LLVM/project a324d96 — llvm/test/CodeGen/AArch64 preserve_nonecc_call.ll

Use ;; for the test comment
DeltaFile
+3-3llvm/test/CodeGen/AArch64/preserve_nonecc_call.ll
+3-31 files

LLVM/project 68ddee7 — llvm/test/CodeGen/AArch64 preserve_nonecc_call.ll

[AArch64] Test the i32 preserve_none argument registers on Windows

CC_AArch64_Preserve_None excludes X15 from the argument registers on
Windows, where it is used for stack allocation, but only the i64 case was
covered by preserve_nonecc_call.ll. Add the i32 counterpart: the 24th i32
argument is passed in w15 on AAPCS and Darwin targets and on the stack on
Windows.

Assisted-by: Claude
DeltaFile
+345-0llvm/test/CodeGen/AArch64/preserve_nonecc_call.ll
+345-01 files

LLVM/project deae563 — clang/lib/CIR/Lowering/DirectToLLVM CMakeLists.txt, flang/lib/Optimizer/CodeGen CMakeLists.txt

[mlir][CIR] Separate OpenMP LLVM conversion helpers from the pass (NFC) (#232766)

Move the standalone OpenMP-to-LLVM pass to its own translation unit.
Keep MLIROpenMPToLLVM as the complete public conversion target, and
provide patterns, legality, and dialect-interface registration through
MLIROpenMPToLLVMConversion.

Use the helper target in CIR lowering and Flang code generation, and
remove the unused conversion dependency from FIRDialect. This breaks the
CIR link path through MemRef conversion and utilities to Affine without
splitting MemRef utilities or moving IR-dependent constraint analysis.

Assisted-by: Codex
DeltaFile
+57-0mlir/lib/Conversion/OpenMPToLLVM/OpenMPToLLVMPass.cpp
+0-41mlir/lib/Conversion/OpenMPToLLVM/OpenMPToLLVM.cpp
+36-2mlir/lib/Conversion/OpenMPToLLVM/CMakeLists.txt
+1-1flang/lib/Optimizer/CodeGen/CMakeLists.txt
+1-1clang/lib/CIR/Lowering/DirectToLLVM/CMakeLists.txt
+2-0mlir/include/mlir/Conversion/OpenMPToLLVM/ConvertOpenMPToLLVM.h
+97-451 files not shown
+97-467 files

LLVM/project 5e8ec81 — clang/lib/Driver/ToolChains CommonArgs.cpp Clang.cpp, clang/test/Driver aarch64-uefi-constructed-args.c aarch64-security-options.c

[clang][Driver] Use the Windows ARM64 defaults for aarch64-unknown-uefi (#232706)

Match the Windows ARM64 driver defaults for aarch64-unknown-uefi, which
follows the same ABI:

* char is signed, so do not pass -fno-signed-char,
* the frame chain must stay valid even when frame pointers are omitted,
  so -fomit-frame-pointer yields -mframe-pointer=reserved rather than
  none, as the backend reserves the frame pointer for UEFI as well,
* -msign-return-address selects the B key, the only one the backend
  accepts for Windows and UEFI.

Tested with the full `check-llvm` / `check-clang` suites and by building
Fuchsia's arm64 EFI binaries (physboot EFI shim, boot tests, gigaboot)
with
a toolchain built from this series.

Assisted-by: Claude
DeltaFile
+9-0clang/test/Driver/aarch64-uefi-constructed-args.c
+9-0clang/test/Driver/aarch64-security-options.c
+4-4clang/lib/Driver/ToolChains/CommonArgs.cpp
+4-4clang/lib/Driver/ToolChains/Clang.cpp
+26-84 files

LLVM/project 91a6410 — clang/lib/Basic/Targets AArch64.h AArch64.cpp, clang/lib/Driver Driver.cpp

[clang] Add aarch64-unknown-uefi target (#232705)

Add the aarch64-unknown-uefi target to clang, building on the backend
support added in the preceding patches. Like x86_64-unknown-uefi it
follows the Microsoft ABI conventions, matching the Windows ARM64 target
which is the only way EFI applications for AArch64 can be built with
Clang/LLVM today:

* add UEFIAArch64TargetInfo: LLP64 types, Microsoft C++ ABI, char*
  based va_list and the Win64 calling convention kind,
* use the Windows AArch64 ABI info in CodeGen for UEFI,
* accept aarch64 for *-uefi triples in the driver.

The UEFI toolchain already handles the linker invocation (lld-link with
/subsystem:efi_application), so no further driver changes are needed.

Tested with the full `check-llvm` / `check-clang` suites and by building
Fuchsia's arm64 EFI binaries (physboot EFI shim, boot tests, gigaboot)
with

    [2 lines not shown]
DeltaFile
+50-0clang/lib/Basic/Targets/AArch64.cpp
+43-0clang/test/CodeGen/AArch64/uefi-abi.c
+19-0clang/test/Driver/aarch64-uefi-constructed-args.c
+14-0clang/lib/Basic/Targets/AArch64.h
+0-6clang/test/Driver/unsupported-target-arch.c
+4-2clang/lib/Driver/Driver.cpp
+130-89 files not shown
+147-915 files

LLVM/project 49c936c — llvm/docs ReleaseNotes.md, llvm/lib/Target/AArch64 AArch64CodeLayoutOpt.cpp AArch64MachineFunctionInfo.cpp

[AArch64] Apply the Windows SEH and CRT codegen constraints to UEFI (#232704)

aarch64-unknown-uefi uses SEH unwind information and has no C runtime
library, so the remaining Windows specific codegen decisions that follow
from this apply to it too:

* do not align loops or basic blocks, since SEH unwind info generation
  needs the exact function layout before alignment padding is inserted,
* sign return addresses with the B key by default and reject A key
  signing, matching the pac_sign_lr unwind code used by the unwinder;
  the branch protection parser defaults to the B key for UEFI as well,
  so that -mbranch-protection=pac-ret keeps working,
* do not lower wide shifts to libcalls at -Oz, as those helpers are not
  available.

The corresponding Windows tests gain aarch64-unknown-uefi run lines and
the LLVM release notes announce the new target, which completes the
backend side of aarch64-unknown-uefi support.


    [5 lines not shown]
DeltaFile
+18-0llvm/unittests/TargetParser/TargetParserTest.cpp
+5-5llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+2-2llvm/lib/TargetParser/ARMTargetParserCommon.cpp
+2-2llvm/lib/Target/AArch64/AArch64MachineFunctionInfo.cpp
+4-0llvm/docs/ReleaseNotes.md
+1-1llvm/lib/Target/AArch64/AArch64CodeLayoutOpt.cpp
+32-103 files not shown
+35-109 files

LLVM/project f05ec3c — llvm/lib/CodeGen/GlobalISel IRTranslator.cpp, llvm/lib/Target/AArch64 AArch64ISelLowering.cpp AArch64Subtarget.cpp

[AArch64] Classify global references on UEFI like Windows COFF (#232703)

Apply the Windows COFF rules for global references to
aarch64-unknown-uefi, which produces the same PE/COFF images:

* classify dllimport and non-dso-local globals with MO_DLLIMPORT /
  MO_COFFSTUB, so extern_weak symbols are referenced through a stub that
  can be resolved to zero by the linker,
* keep the existing SelectionDAG, FastISel and GlobalISel handling of
  calls and tail calls to extern_weak functions in sync with that,
* default to the PIC relocation model, so jump tables and other
  references stay position independent in relocatable PE images,
* lower ifuncs on UEFI as COFF has no support for them.

The extern weak and jump table tests gain aarch64-unknown-uefi run
lines,
and a new test checks that the default pipelines lower ifuncs for both
Windows and UEFI.


    [5 lines not shown]
DeltaFile
+47-0llvm/test/CodeGen/AArch64/ifunc-lower-coff.ll
+3-3llvm/lib/Target/AArch64/AArch64TargetMachine.cpp
+3-3llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
+2-2llvm/lib/Target/AArch64/AArch64Subtarget.cpp
+2-1llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+3-0llvm/test/CodeGen/AArch64/windows-extern-weak.ll
+60-93 files not shown
+63-119 files

LLVM/project 7a5c15f — llvm/lib/Target/AArch64 AArch64MachineFunctionInfo.cpp AArch64ISelLowering.cpp, llvm/test/CodeGen/AArch64 win-alloca-no-stack-probe.ll no-stack-arg-probe.ll

[AArch64] Probe large stack frames with __chkstk on UEFI (#233642)

Like Windows, aarch64-unknown-uefi has no guard page handling of its
own, so frames larger than the probe size are probed with __chkstk
instead of inline probing, and "no-stack-arg-probe" disables it.

Tests: chkstk.ll, no-stack-arg-probe.ll and
win-alloca-no-stack-probe.ll.

Assisted-by: Claude
DeltaFile
+1-1llvm/lib/Target/AArch64/AArch64MachineFunctionInfo.cpp
+1-1llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+1-1llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
+2-0llvm/test/CodeGen/AArch64/no-stack-arg-probe.ll
+2-0llvm/test/CodeGen/AArch64/chkstk.ll
+1-0llvm/test/CodeGen/AArch64/win-alloca-no-stack-probe.ll
+8-36 files

LLVM/project e61b856 — llvm/lib/TargetParser AArch64TargetParser.cpp, llvm/test/CodeGen/AArch64 arm64-platform-reg.ll

[AArch64] Reserve x18 as the platform register on UEFI (#232701)

Both the Windows ARM64 ABI, which UEFI follows, and the firmware
ecosystem (EDK2 builds AArch64 with -ffixed-x18) treat x18 as a reserved
platform register. Reserve it by default for aarch64-unknown-uefi, as is
already done for Windows, Darwin, Android, Fuchsia and OHOS.

Tested with the full `check-llvm` / `check-clang` suites and by building
Fuchsia's arm64 EFI binaries (physboot EFI shim, boot tests, gigaboot)
with
a toolchain built from this series.

Assisted-by: Claude
DeltaFile
+1-1llvm/lib/TargetParser/AArch64TargetParser.cpp
+1-0llvm/test/CodeGen/AArch64/arm64-platform-reg.ll
+2-12 files

LLVM/project cdb265e — llvm/include/llvm/IR RuntimeLibcalls.td, llvm/lib/CodeGen/GlobalISel IRTranslator.cpp

[AArch64] Use __chkstk for dynamic stack allocation on UEFI (#232702)

Register the Windows __chkstk stack probe helper for
aarch64-unknown-uefi
and lower dynamic stack allocations through it, including the SME ZA
buffer allocation in LowerFormalArguments. GlobalISel falls back to
SelectionDAG for dynamic allocas on UEFI as it does on Windows.

Tests: win-alloca.ll, the vla in win64_vararg.ll (which now runs in full
on UEFI) and sme-lazy-save-windows.ll.

Assisted-by: Claude
DeltaFile
+3-2llvm/include/llvm/IR/RuntimeLibcalls.td
+2-2llvm/lib/Target/AArch64/MachineSMEABIPass.cpp
+2-2llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+2-2llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
+2-0llvm/test/CodeGen/AArch64/win-alloca.ll
+1-0llvm/test/CodeGen/AArch64/win64_vararg.ll
+12-81 files not shown
+13-87 files

LLVM/project d9c11d9 — llvm/lib/Target/AArch64 AArch64ISelLowering.cpp AArch64FrameLowering.cpp, llvm/test/CodeGen/AArch64 win64cc-backup-x18.ll

[AArch64] Treat the Win64 calling convention as native on UEFI (#233641)

Functions using the Win64 calling convention on a non-Windows target
back up x18 and are excluded from tail call optimization, because x18
is the platform register there. On UEFI the Win64 convention is the
native one, so apply the Windows behaviour.

Tests: win64cc-backup-x18.ll gains Windows and UEFI run lines showing
that neither backs up x18 and both tail call.

Assisted-by: Claude
DeltaFile
+8-0llvm/test/CodeGen/AArch64/win64cc-backup-x18.ll
+1-1llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+1-1llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
+10-23 files

LLVM/project 9104094 — llvm/lib/Target/AArch64 AArch64Subtarget.h AArch64CallingConvention.td, llvm/lib/Target/AArch64/GISel AArch64LegalizerInfo.cpp

[AArch64] Use the Win64 calling convention and va_list on UEFI (#233640)

UEFI follows the Windows ARM64 procedure call standard, as
x86_64-unknown-uefi already follows the Win64 one. Use it for C, Fast
and Swift calls on aarch64-unknown-uefi: the Win64 variadic convention
(all remaining argument registers are homed and floating point variadic
arguments travel in GPRs), the char* va_list for va_copy, and the
preserve_none variant that follows the Win64 rules.

LowerVACOPY and the GlobalISel va_copy legalization used to re-derive
sizeof(va_list) and the pointer size from target-triple conditionals,
duplicating AArch64TargetLowering::getVaListSizeInBits. They now use the
DataLayout pointer size and getVaListSizeInBits, so the
Darwin/Windows/UEFI vs. AAPCS decision lives in one function. This also
fixes getVaListSizeInBits for ILP32, which returned 256 bits instead of
160.

Tests: win64_vararg_float.ll (SelectionDAG, FastISel and GlobalISel),
win64_vacopy.ll (SelectionDAG and GlobalISel va_copy),

    [10 lines not shown]
DeltaFile
+23-0llvm/test/CodeGen/AArch64/win64_vacopy.ll
+10-11llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+11-0llvm/test/CodeGen/AArch64/GlobalISel/legalize-vacopy.mir
+3-6llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp
+3-3llvm/lib/Target/AArch64/AArch64CallingConvention.td
+2-2llvm/lib/Target/AArch64/AArch64Subtarget.h
+52-225 files not shown
+60-2511 files

LLVM/project f19efc3 — llvm/lib/Target/AArch64 AArch64RegisterInfo.cpp AArch64Subtarget.h, llvm/test/CodeGen/AArch64 regress-w29-reserved-with-fp.ll uefi-frame-record-pairing.ll

[AArch64] Use the Windows callee saved registers and frame chain on UEFI (#232700)

aarch64-unknown-uefi already emits Windows (SEH) unwind info, but
CodeGen
still used the AAPCS callee saved register order, which produces
non-consecutive save_regp pairs and trips the "Non-consecutive registers
not allowed for save_regp" assertion for any function with a frame
record. Introduce AArch64Subtarget::isTargetUEFI() and
isTargetWindowsOrUEFI() and use the latter for the Windows callee saved
register list, the matching frame record pairing rules, and the
requirement that the frame chain stays valid in every function.

Tests: uefi-frame-record-pairing.ll (prologue pairing and the object
file) and regress-w29-reserved-with-fp.ll (x29 reserved by default).

Assisted-by: Claude
DeltaFile
+47-0llvm/test/CodeGen/AArch64/uefi-frame-record-pairing.ll
+6-7llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
+7-0llvm/lib/Target/AArch64/AArch64Subtarget.h
+2-1llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp
+2-0llvm/test/CodeGen/AArch64/regress-w29-reserved-with-fp.ll
+64-85 files

LLVM/project 6e00095 — llvm/lib/Target/AArch64 AArch64MCInstLower.cpp, llvm/lib/Target/AArch64/MCTargetDesc AArch64MCTargetDesc.cpp

[AArch64] Use the Microsoft COFF MCAsmInfo for UEFI targets (#232699)

This is the first in a series of patches adding aarch64-unknown-uefi
support to the AArch64 backend and clang.

UEFI follows the MSVC toolchain conventions and lld-link is used to
produce the PE/COFF images, so aarch64-unknown-uefi should use the
Microsoft COFF MCAsmInfo like the X86 backend already does for
x86_64-unknown-uefi, rather than the GNU (MinGW) flavour it currently
gets by virtue of being a non-MSVC COFF triple. This enables associative
COMDATs and COMDAT constant pool entries (which AsmPrinter already
expects for UEFI, see GetCPISymbol).

Also relax the AArch64MCInstLower assertion that only Windows COFF
targets exist.

Tested with the full `check-llvm` / `check-clang` suites and by building
Fuchsia's arm64 EFI binaries (physboot EFI shim, boot tests, gigaboot)
with

    [2 lines not shown]
DeltaFile
+2-2llvm/lib/Target/AArch64/AArch64MCInstLower.cpp
+1-1llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCTargetDesc.cpp
+1-0llvm/test/CodeGen/AArch64/win_cst_pool.ll
+4-33 files

FreeBSD/ports 30daab4 — databases Makefile

databases/kividb: connect to the build

Reported by:    vanilla

Sponsored by:   tipi.work
DeltaFile
+1-0databases/Makefile
+1-01 files

HardenedBSD/ports 30daab4 — databases Makefile

databases/kividb: connect to the build

Reported by:    vanilla

Sponsored by:   tipi.work
DeltaFile
+1-0databases/Makefile
+1-01 files

LLVM/project ec5ac8d — llvm/lib/Transforms/Scalar JumpThreading.cpp, llvm/test/Transforms/JumpThreading split-block-profile.ll

[JumpThreading] Propagate unknown profiles (#234022)

Otherwise if a previous pass creates an unknown profile we never mark
the new branch which causes a verification failure.
DeltaFile
+33-0llvm/test/Transforms/JumpThreading/split-block-profile.ll
+3-0llvm/lib/Transforms/Scalar/JumpThreading.cpp
+36-02 files

LLVM/project d288721 — mlir/lib/Conversion/MathToFuncs MathToFuncs.cpp, mlir/test/Conversion/MathToFuncs symbol-tables.mlir

[mlir] Place MathToFuncs helpers in the nearest symbol table (#232582)

The MathToFuncs pass previously inserted every outlined ipowi, fpowi,
and ctlz helper into the top-level builtin.module. Calls rewritten
inside a gpu.module could not resolve those helpers because the
declarations were outside the nearest symbol table.

Create each helper in the symbol table nearest to its source operation.
Include that symbol table in the implementation cache key, and use the
same key when looking up helpers during conversion. This preserves reuse
for repeated calls in one module without sharing a definition across
distinct gpu.modules or the host module.

AI assistance: Portions of this patch and its regression test were
developed with assistance from OpenAI Codex. I have reviewed and
understand the submitted changes, and I take responsibility for them.
DeltaFile
+134-0mlir/test/Conversion/MathToFuncs/symbol-tables.mlir
+34-24mlir/lib/Conversion/MathToFuncs/MathToFuncs.cpp
+168-242 files

LLVM/project 18e8fed — lldb/include/lldb/Core PluginManager.h, lldb/include/lldb/Interpreter CommandOptionArgumentTable.h

[lldb] List registered extensions in `help scripting-extension` (#232891)

`help scripting-extension` only printed a one-line description, while
tab completion for the same argument offered every registered scripted
extension. Help and completion come from separate parts of the argument
table: completion queries PluginManager at runtime, but help only
printed the entry's static text.

This PR changes the argument table entry for ScriptedExtension to add a
help callback that lists the registered extensions along with the
description each interface registered with. The list is built from the
plugin registry rather than a static enum table because not every
lldb::ScriptedExtension value has a registered interface (e.g.
ParsedCommand), and a static table would advertise names that completion
never offers.

This also refactors the registry walk into a single
`PluginManager::ForEachScriptedExtension` so completion and help share
it.

    [3 lines not shown]
DeltaFile
+19-48lldb/source/Core/PluginManager.cpp
+43-0lldb/include/lldb/Core/PluginManager.h
+27-0lldb/source/Commands/CommandOptionArgumentTable.cpp
+2-1lldb/include/lldb/Interpreter/CommandOptionArgumentTable.h
+91-494 files

LLVM/project 9931cfb — llvm/lib/Transforms/Vectorize SLPVectorizer.cpp, llvm/lib/Transforms/Vectorize/SLPVectorizer SLPMemoryUtils.h SLPCostAnalysis.cpp

Revert "[SLP] Use costing to decide between Strided Loads and Compressed Load…"

This reverts commit e426a42b1547a8732e6adf64e1bda338aa96acdb.
DeltaFile
+29-121llvm/test/Transforms/SLPVectorizer/RISCV/revec-strided-load.ll
+55-85llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+51-26llvm/lib/Transforms/Vectorize/SLPVectorizer/SLPMemoryUtils.cpp
+67-5llvm/test/Transforms/SLPVectorizer/RISCV/reductions.ll
+0-64llvm/lib/Transforms/Vectorize/SLPVectorizer/SLPCostAnalysis.cpp
+27-10llvm/lib/Transforms/Vectorize/SLPVectorizer/SLPMemoryUtils.h
+229-3114 files not shown
+242-35710 files

LLVM/project c759b57 — libc/src/__support/File/linux popen_file.h file.cpp, libc/src/__support/OSUtil/linux shell_fork.h

[libc] implement popen/pclose (#232846)

This is a deceptively complex set of functions. They need to have
their own FILE subclass to track the PID of the child process and a list
of other open files specifically for popen. I also ended up refactoring
`system` since it shares the fork-and-shell mechanism. The POSIX
definition is here:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/popen.html

Assisted-by: Automated tooling, human reviewed.
DeltaFile
+158-0libc/test/src/stdio/popen_pclose_test.cpp
+132-0libc/src/stdio/linux/popen.cpp
+81-0libc/src/__support/OSUtil/linux/shell_fork.h
+28-41libc/src/__support/File/linux/file.cpp
+66-0libc/src/__support/File/linux/popen_file.h
+18-44libc/src/stdlib/linux/system.cpp
+483-8521 files not shown
+916-10727 files

LLVM/project 016b90f — llvm/docs/CommandGuide llvm-mc.md, llvm/test/tools/llvm-mc/verify disassemble-zos.txt

[nspr] update
DeltaFile
+23-18llvm/docs/CommandGuide/llvm-mc.md
+3-2llvm/test/tools/llvm-mc/verify/disassemble-zos.txt
+26-202 files

LLVM/project 4c8c4ae — llvm/docs/CommandGuide llvm-mc.md, llvm/include/llvm/Support SourceMgrDiagnosticVerifier.h

[nspr] initial commit
DeltaFile
+24-4llvm/test/tools/llvm-mc/verify/basic.s
+21-3llvm/lib/Support/SourceMgrDiagnosticVerifier.cpp
+19-1llvm/unittests/Support/SourceMgrDiagnosticVerifierTest.cpp
+4-1llvm/docs/CommandGuide/llvm-mc.md
+5-0llvm/include/llvm/Support/SourceMgrDiagnosticVerifier.h
+1-1mlir/lib/IR/Diagnostics.cpp
+74-106 files

OpenZFS/src 550ee40 — module/os/linux/zfs zfs_vfsops.c

Linux: don't dereference NULL z_ctldir in zfs_vget() for snapshots

A snapshot's zfsvfs never gets a .zfs control directory (zfsctl_create()
is skipped for z_issnap), but z_show_ctldir keeps its default value
because property callbacks are not registered for snapshots.  A short
file handle for ZFSCTL_INO_ROOT or ZFSCTL_INO_SNAPDIR with a zero
generation, presented on a mounted snapshot, therefore sets *ipp to
NULL in zfs_vget(), which a debug build catches with
"VERIFY(*ipp != NULL) failed".

Return ENOENT when there is no control directory, the same as when
snapdir=disabled.

This makes snapdir_fh_ctldir, added in the previous commit, pass.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Will Rouesnel <wrouesnel at wrouesnel.com>
Closes #19290
DeltaFile
+7-2module/os/linux/zfs/zfs_vfsops.c
+7-21 files