bhyve/riscv: fix PCIe FDT interrupt-map entry stride
In bhyve arm64, each PCIe interrupt-map entry spans 10 cells because the
ARM GIC specifies #interrupt-cells = 3. On RISC-V, the APLIC uses
#interrupt-cells = 2, so each entry spans only 9 cells.
When the PCIe FDT code was originally adapted from arm64, the property
allocation size and cell assignments were reduced to 9 cells per entry,
but the loop multiplier retained the 10-cell stride. This caused the
interrupt-map array to be packed incorrectly with gaps, breaking PCI
interrupt routing in guest operating systems and overflowing the
allocation by 16 cells.
Correct the loop stride to 9 cells so the interrupt map is properly
formed.
Reviewed by: jrtc27
Fixes: 7ab1a32cd43c ("bhyve/riscv: Initial import")
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D61473
[IR] Verify that wchar_size module flag is positive (#241150)
A zero `wchar_t` size is meaningless and would cause problems when
adding certain wide character functions to RuntimeLibcalls. For example,
it would be impossible to declare `wmemset` because its signature
depends on the size of `wchar_t`.
Also remove the now-redundant zero check from optimizeWcslen().
Assisted-by: Claude
[SPARC] Remove the UT699 errata workarounds (#237953)
They do not cover all necessary workarounds and are not documented
and unlikely to be used. UT699 has been succeeded by UT699E/UT700,
so even if adding the missing workarounds they are unlikely to be used.
The workaround for AT697F could be made more efficient, but it looks
correct. Fold the pass into the errata workaround pass.
Assisted-by: Claude
[llvm][test] Require default_triple in tests without a target triple (NFC) (#241914)
These tests run llc or llvm-lto on IR without a target triple. If the
native target is not built, the default triple is empty and they fail
with "unable to get target for ''".
Co-Authored-By: Claude Opus 5.5
---------
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[VE] Define the whole register when extending i32 to i64. NFC.
sext, zext and sext_inreg from i32 to i64 were selected to adds.w.sx or
adds.w.zx with an i32 result, followed by INSERT_SUBREG into an
IMPLICIT_DEF, which claims that the high 32 bits are undefined. These
instructions sign or zero extend the result into the whole 64-bit
register, so add codegen-only variants with i64 results and the same
encodings, and use them instead.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[mlir][tosa] Use `mxi8` builtin type for EXT-MX-INT8 operations (#241850)
Replace the custom `!tosa.mxint8` type with the new builtin `mxi8` type.
Deprecate `!tosa.mxint8` and keep periodically for compatibility with
existing IR.
[VE] Use the 64-bit ldl.zx for the pack_f32p and pack_f32a intrinsics. NFC.
The patterns for these intrinsics rely on ldl.zx clearing the high 32
bits of the register, but used INSERT_SUBREG into an IMPLICIT_DEF of its
i32 result, which claims that the high 32 bits are undefined. Use the
variant of ldl.zx that defines the whole 64-bit register instead.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[VE] Use the 64-bit extending loads for extended atomic loads. NFC.
The patterns for sign and zero extended atomic loads to i64 used
INSERT_SUBREG into an IMPLICIT_DEF of the i32 result of the load, which
claims that the high 32 bits are undefined. Use the variants of the
loads that define the whole 64-bit register instead.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[SelectionDAG] Lower vector `bitinsert` and `bitextract` (#240586)
Lower vector `bitinsert` and `bitextract` in SelectionDAG.
The scalar lowering already works for vectors. Only the width asserts
change, to compare element sizes.
Adds tests for X86, AArch64 (NEON and SVE), RISC-V (fixed and scalable)
and AMDGPU.
[InstSimplify][InstCombine] Add vector tests for `bitinsert` and `bitextract` (NFC) (#240197)
Add vector tests for the `bitinsert` and `bitextract` folds that already
work on scalar types.
Vectors were not implemented when the following landed, so none of them
had vector tests:
- ConstantFolding's `poison` early exits (#229115).
- InstSimplify's out-of-range splat offsets, full-width forms, and
`bitextract`/`bitinsert` round trips (#229125).
- InstCombine's full-width `bitcast` folds (#229147).
It also adds negative tests where only some elements of the offset are
out of range or `poison`. Those elements become `poison`.
[IR] Allow vectors in `bitinsert` and `bitextract` (#240182)
Allow vector operands in `bitinsert` and `bitextract`.
These follow an element-wise semantics, like `shl` or `trunc`:
- Each result element reads or writes the corresponding source element,
at the corresponding offset.
- The offset is a vector of `i32`, with the same number of elements as
the other operands.
- Scalars and vectors can't be mixed, and the width checks apply to the
elements.
- An out-of-range offset only makes its own element `poison`.
- Scalable vectors are allowed.
```llvm
%a = bitextract <2 x i8>, <2 x b32> %src, <2 x i32> <i32 0, i32 24>
%b = bitinsert <2 x b32> %x, <2 x i8> %y, <2 x i32> splat (i32 8)
```
[8 lines not shown]
[AMDGPU][NFC] Explicitly narrow conversions in asm printing and MIR formatting (#215195)
This fixes 32 instances of MSVC warning C4244 and 1 of C4267 ("possible loss of data") across 6 files in llvm/lib/Target/AMDGPU.
Assisted-by: Claude <noreply at anthropic.com>
[mlir][GPUToNVVM] Lower cluster-scoped gpu.barrier to cluster barrier ops (#238732)
Lower gpu.barrier with scope <cluster> to nvvm.cluster.arrive (or
nvvm.cluster.arrive.relaxed when memfence [] is specified) followed by
nvvm.cluster.wait, both with the aligned attribute set. Also add the
missing NVVMRequiresSM<90> trait to NVVM_ClusterArriveOp to match
NVVM_ClusterArriveRelaxedOp and NVVM_ClusterWaitOp.
Assisted-by: Gemini
NAS-145038 / 28.0.0-BETA.1 / Add webui.dataset.details and move pool.dataset.details onto zfs.resource (#20102)
## Context
This adds the machinery the WebUI needs to move off
`pool.dataset.details` without breaking today's contract.
`pool.dataset.details` keeps returning exactly what it returns now, so
the current UI keeps working unchanged, and the new
`webui.dataset.details` is there for the Datasets page to switch to when
it's ready.
- **pool.dataset.details** now gets its data from zfs.resource instead
of the legacy query engine, as part of retiring the pool.dataset
namespace. Its output is unchanged.
- **webui.dataset.details** lives in the webui namespace rather than
zfs.resource. It exists to give the Datasets page everything it shows in
one cheap call: every dataset, plus the shares, VMs, containers, apps
and data protection tasks that use it. That is a join across most of the
plugins that consume storage, and zfs.resource shouldn't depend on its
own consumers.
[7 lines not shown]
[VE] Define the whole register in 8 and 16-bit extending loads to i64. NFC.
As for ldl.sx and ldl.zx, the ld1b and ld2b loads sign or zero extend
into the whole 64-bit register. Add codegen-only variants with i64
results and use them for extending loads to i64, instead of
INSERT_SUBREG into an IMPLICIT_DEF of the i32 result, which claims that
the high 32 bits are undefined.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[VE] Define the whole register in 32-bit extending loads to i64. NFC.
ldl.sx and ldl.zx sign or zero extend the loaded value into the whole
64-bit register, but they were only defined with i32 results. Extending
loads to i64 then used INSERT_SUBREG into an IMPLICIT_DEF, which claims
that the high 32 bits are undefined, and the SjLj dispatch block used
SUBREG_TO_REG.
Add codegen-only variants of ldl.sx and ldl.zx with i64 results and the
same encodings, and use them for both.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[WebAssembly] Lower wide vector extend (#238384)
For v16i8 -> v16i32 we already use a tree of extend_low / _high to
extend vectors that are larger than legal, so increase the support for
v8i8, v8i16 and v16i16.
if_geneve: Ignore reserved bits on receive
RFC 8926 section 3.4 requires the reserved fields of geneve header
to be ignored on receipt.
While here, remove the needless htons() from the version check, as
geneve_ver is a 2-bit bitfield with no byte order.
Fixes: e44d2e941e8e ("if_geneve: Add Support for Geneve (RFC8926)")
if_geneve: Ignore reserved bits on receive
RFC 8926 section 3.4 requires the reserved fields of geneve header
to be ignored on receipt.
While here, remove the needless htons() from the version check, as
geneve_ver is a 2-bit bitfield with no byte order.
Fixes: e44d2e941e8e ("if_geneve: Add Support for Geneve (RFC8926)")
if_geneve: Do not byte-swap the option length
geneve_optlen is a 6-bit bitfield within a single byte, so it has no
byte order. Applying ntohs() to it on little-endian machines turned
an option length of 1 into 256, causing every received packet carrying
options to dropped.
PR: 300453
Reviewed by: pouria
Fixes: e44d2e941e8e ("if_geneve: Add Support for Geneve (RFC8926)")
if_geneve: Do not byte-swap the option length
geneve_optlen is a 6-bit bitfield within a single byte, so it has no
byte order. Applying ntohs() to it on little-endian machines turned
an option length of 1 into 256, causing every received packet carrying
options to dropped.
PR: 300453
Reviewed by: pouria
Fixes: e44d2e941e8e ("if_geneve: Add Support for Geneve (RFC8926)")
