[mlir][OpenMP] Don't allow loop bounds/step from inside the task
The omp.taskloop.context region represents what goes inside the outlined
task function. The loop bounds must be passed to the OpenMP runtime call
for taskloop and so this cannot be supported in general.
In a follow up patch I will re-allow pure operations because sinking
constants inside of the tasklooop context will be useful for something
else I am prototyping.
Assisted-by: codex
[llvm-exegesis] Pass data layout explicitly to LLJIT (#190789)
This is a defesive change that aims to make sure the target data layout
of both the object compilation and LLJIT is the same, by passing it
explicitly rather than relying similar auto-detection implicitly.
The patch doesnt add a new test but relies on existing ones, as a test
case of different layouts would require to exhibit a misuse of the tool,
doing cross-compilation to change the layout of the compilation. The
tool is not designed to work this way.
[mlir][vector] Replace unused shuffle operands / results with poison (#190763)
If a shuffle operand is not used (as indicated by the mask), replace it
with `ub.poison`. This may make the value dead and enable additional
DCE. Also replace the entire shuffle op with `ub.poison` if all selected
values are poisoned.
Assisted-by: claude-4.6-opus-high
hwpstate_amd: Expose nodes as much as possible in legacy pstate
Reviewed by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55606
[MLIR][NVVM] Add family-specific support to NVVMRequiresSM traits (#185909)
This change adds support for family-conditional SM version requirements
to the `NVVMRequiresSM` traits. The following new traits are added:
- `NVVMRequiresSMf` - Op requires an SM version belonging to one of the
given families.
- `NVVMRequiresSMaOrSMf` - Op requires one of the supported
arch-accelerated versions or an SM version belonging to one of the given
families.
This also changes the underlying checks to use the `FullSMVersion`
instead of booleans to indicate arch-acceleration and family-specific
support to simplify the checks.
contrib/libucl: Revert to old behavior of macros
Enable macros and includes by default as this is breaking package
building on HEAD. libucl 0.9.3 by default changed the behavior of
includes and macros. These were previously enabled but it switched to
disabled which breaks the package building in HEAD. This is a temporary
workaround for now to fix the package building specially for
releng/15.0. This might be reverted post EOL of 15.0 in the coming
months.
Reported by: ivy
Fixes: abda442d92fd ("contrib/libucl: Import libucl 0.9.3")
Tested by: ivy
Approved by: ivy, kevans
Differential Revision: https://reviews.freebsd.org/D56294
Mk/Uses/java.mk: re-order preferred JDK (latest LTS over non-LTS)
Old order:
1. JAVA_DEFAULT
2. The oldest JDK in the JAVA_VERSION range.
New order:
1. JAVA_DEFAULT (unchanged)
2. The latest LTS from the JAVA_VERSION range is preferred over non-LTS versions.
Other existing mechanisms are unchanged. Like looking at what JDKs are already
installed.
This only affects 17 ports. (see the issue for the list)
PR: 293756
[Hexagon] Fix O(N^2) compile-time regression in HexagonOptAddrMode (#189531)
In HexagonOptAddrMode::processAddUses, isSafeToExtLR was called inside
the loop over UNodeList with loop-invariant arguments. isSafeToExtLR
iterates over UNodeList, so the total work was O(N^2) in the number of
uses.
The arguments (AddSN, AddMI, BaseReg, UNodeList) do not change across
iterations. Move the call to after the loop; the function returns the
same value regardless of which iteration calls it, and the complexity
drops to O(N).
Background
----------
Commit 8c0483bba2d2 ("RegisterCoalescer: Fix assert on remat to
copy-to-physreg with subregs") introduced register coalescer
rematerialization changes that produce additional uses of A2_addi
instructions on the Hexagon backend, inflating UNodeList. This exposed
the pre-existing O(N^2) behavior in processAddUses.
[12 lines not shown]
[orc-rt] Rename ManagedCodeCallsGroup to ManagedCodeTaskGroup. NFC. (#190880)
The new name better reflects this group's purpose: Tokens are needed for
any task that wants to access managed code, whether to call it or access
data.
[NFC][RISCV] Fix mismatched closing comment in XSfmm instruction definition (#190898)
The closing comment had XSfmm64a32f but the opening predicate uses
XSfmm32a32f.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
bsd.own.mk: sort various lists and expressions
Sort various lists of variables.
(Manually) sort various .if expressions on platform name.
Should be no functional change, but easier to cross-check mk.conf(5).
