[CodeGen] Use RegisterClassInfo for remaining allocation-order users (#216510)
Greedy already uses RegisterClassInfo for the function-specific
allocation order (reserved registers filtered, CSRs deferred). Remaining
users still walked TRI's raw order or rebuilt RCI themselves.
Uses RCI.getOrder() everywhere that list is needed (PBQP, Hexagon
spill-slot search*, ARM load/store opt, AMDGPU AGPR-copy MFMA rewrite).
Takes the shared analysis when the pass can preserve it; otherwise keep
a
local RCI after freezeReservedRegs().
Hexagon findPhysReg no longer considers reserved registers.
**Note:** Initially had register scavenger use RCI.getOrder() for
function specific scratch reg allocation, but due to test failures and
the extra loops needed as fallbacks to fix this, this change ends up
likely being outside the scope of this PR so I removed it.
**Another note:** \*Hexagon changes removed from this PR, split into
#216752
website: Revive mailto as contact
Mailto is an important page, one of the many that was lost in the reorg.
Revive it as freebsd.org/contact, and move it to the legal column in the
footer. The bottom heading of mailto used to be commercial vendors, zap
that and replace it with a legal section for the freebsd foundation.
Also simplify some of the language a bit.
Adding core as a *non-blocking* reviewer so they can weigh in if they
desire, but I think this is extremely positive and reasonable and we can
keep iterating, so I do not intend to wait for them unless they ask.
Event: Berlin Hackathon 202609
Reviewed by: wosch
Suggested by: wosch
Differential Revision: https://reviews.freebsd.org/D59442
website: Overhaul ports visibility
header: move ports to Get FreeBSD
footer: add ports, remove 44bsd docs archive. It is still in docs/
where/: remove ports, and remove it from the sidemenu
Event: Berlin Hackathon 202609
Reviewed by: wosch
Suggested by: wosch, michaelo
Differential Revision: https://reviews.freebsd.org/D59442
ARM: Form fused VFMA/VFMS from the contract flag (#221340)
Select the fused VFMA/VFMS/VFNMA/VFNMS from the per-node contract
fast-math flag instead of the global AllowFPOpFusion == Fast. This is one of the
few remaining consumers of the TargetOption field.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[CIR][OpenCL] Lower OpenCL language version metadata to LLVM dialect
Propagate CIR OpenCL language version module attributes as LLVM dialect named metadata before LLVM IR translation.
Assisted-by: Codex / GPT-5.6 Sol
fix: Supply the HIP SPIR-V version only for metadata emission
Fix the assertion exposed by PR #214246 under the version invariant from PR #219687. Supply OpenCL 2.0 in classic CodeGen and CIRGen without changing HIP language options or enabling OpenCL-only Sema restrictions.
Assisted-by: Codex / GPT-6
[CIR][OpenCL] Emit OpenCL language version metadata in CIR
Emit OpenCL and C++ for OpenCL language version attributes from CIRGen. Preserve the compatible OpenCL version and the C++ for OpenCL version separately so later lowering does not infer one from the other.
Assisted-by: Codex / GPT-5.6 Sol
[CIR][OpenCL] Add OpenCL language version module attributes
Add structured CIR module attributes for OpenCL and C++ for OpenCL language versions. Verify their module-level placement and version components so lowering can consume explicit source-language version state.
Assisted-by: Codex / GPT-5.6 Sol
MC: Move BinutilsVersion from TargetOptions to MCTargetOptions
BinutilsVersion has no codegen use and only used by MCAsmInfo to check
ELF assembler features.
Co-authored-by: Claude (claude-opus-4.8) <noreply at anthropic.com>
[libc++][NFC] Avoid empty namespace in `<__concepts/common_with.h>` (#221407)
...in pre-C++20 modes. This fixes complaining from clang-tidy checks in
CI.
multimedia/ffmpeg: Update to 9.0.1
Support for (lib)celt, (lib)glslang and (lib)shaderc is removed upstream
Remove support for (lib)lensfun as it doesn't work with the old release
we have in tree
Changelog:
https://code.ffmpeg.org/FFmpeg/FFmpeg/src/tag/n9.0.1/Changelog
PR: 297355
Exp-run by: antoine
[OpenMPOpt] Ask the runtime how many of a block's threads can be workers
The custom state machine gates a thread on InitCB < BlockHwSize - WarpSize,
reconstructing the number of worker threads from the block size on the
assumption that the main thread occupies a whole warp above them. The DeviceRTL
already computes that number, in mapping::getMaxTeamThreads(), and its own
generic state machine gates on it in shouldEnterStateMachine(). Export it as
__kmpc_get_max_team_threads() and call that instead, so the compiler's state
machine and the runtime's agree by construction rather than by arithmetic that
has to be kept in step with the launch geometry.
This is NFC here: getMaxTeamThreads() in generic mode is BlockSize - WarpSize,
the same three instructions folded into one call. It is not NFC for a toolchain
whose launch geometry differs. In ROCm, CGOpenMPRuntimeGPU starts a single extra
thread rather than a warp -- "Only one additional thread is started, not an
entire warp" -- so thread_limit(1024) on a 64-lane target launches 961 threads
and the runtime reports 960 workers, while the state machine's own arithmetic
says 961 - 64 = 897. The threads in between are in neither group: the state
machine returns immediately for them, and the parallel region still hands them
[12 lines not shown]
