[mlir][VectorToLLVM] Use the converted index type in vector.type_cast
`VectorTypeCastOpConversion` hardcoded `i64` for the offset, size and stride
constants it inserts into the target memref descriptor, while the descriptor's
fields have the converted index type. With a type converter configured for a
32-bit index the pattern therefore emitted invalid IR:
'llvm.insertvalue' op Type mismatch: cannot insert 'i64' into
'!llvm.struct<(ptr, ptr, i32)>'
Build the constants from the converted index type instead.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[WebAssembly] Avoid same-block dominance walks in RegStackify (NFCI) (#218369)
RegStackify asks whether one use dominates the others.
But when both uses are in the same block, MachineDominatorTree answers
that by walking the block from the start.
Use the SlotIndexes already available here instead.
This avoids repeatedly walking over DBG_VALUEs and other instructions in
large blocks.
pf: Re-optimize state key handling
pf states may be looked up using one of two keys: the stack key or the
wire key. For states involving address translation, these will be
distinct; the stack key describes the addresses seen by the local
network stack, and the wire key has the translated addresses.
Historically, pf would avoid allocating separate keys if both are
identical. This changed in commit fcdb520c1b4e ("pf: nat64") to always
allocate separate state key structures. Incidentally, OpenBSD seems to
maintain the optimization, but also has an explicit reference count
embedded in state keys.
The change breaks another optimization: pf_state_key_attach() still uses
state key pointer equality to check whether the stack and wire keys are
equal, so those checks are always false after the aforementioned commit.
Thus we never skip the second key lookup, even when that's possible
(i.e., no address translation is involved).
[13 lines not shown]
[AMDGPU] Canonicalize num_records to its actual width in InstCombine
llvm.amdgcn.make.buffer.rsrc is overloaded on the type of its
num_records argument, but the hardware field it ends up in has a fixed
width (32 bits, or 45 bits on gfx1250 and up). Rewrite the intrinsic to
use that width, zero-extending or truncating num_records as needed, so
that IR-level optimizations can see that the extra bits of, for example,
the i64 that Clang emits are not demanded.
Targets that aren't concrete enough for the buffer resource layout to be
known are left alone.
AI disclosure: This was my idea but Claude wrote the code (and I've
tried to tighten up the comments)
[AMDGPU] Pre-commit tests for num_records canonicalization
Add tests for having InstCombine canonicalize the num_records argument
of llvm.amdgcn.make.buffer.rsrc to the width it will ultimately have,
which lets later passes see that, for example, the high bits of the i64
that Clang emits aren't used.
AI disclosure: Claude generated these and I've looked at them
[mlir][AMDGPU] Emit num_records at the buffer resource's actual width (#217139)
makeBufferRsrc() zero-extended num_records to i64 on targets whose
buffer resource has a 45-bit num_records field, leaving 19 bits that the
hardware will never look at. Emit an i45 instead, which is what
rocdl.make.buffer.rsrc will end up putting in the descriptor anyway, so
that downstream consumers can see that those bits aren't demanded.
While here, factor the i32 and i64 conversion helpers into a shared
convertUnsignedToInt() that takes the target width.
AI disclosure: Claude made this, I looked at and poked the design into
shape.
---
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
[AMDGPU] Use real num_records width in LowerBufferFatPointers (#217138)
The out-of-bounds analysis in LowerBufferFatPointers took the
num_records operand of llvm.amdgcn.make.buffer.rsrc at face value, which
went wrong in four ways.
1. The pass would crash if num_records was narrower than the
underlying hardware width.
2. A 45-bit num_records with its high bit set made all offsets look
negative, which, among other things, broke the `(1 << 45) - 1` "no
bounds checking" value.
3. The test for all-1 num_records wasn't accounting for hardware
width, leading to false positives if the num_records field was
narrower tan the underlying field.
4. We'd end up trying to do reasoning about num_records when its width
wasn't known - now we don't.
AI disclosure: Claude found and took a try at fixing these, I've
reviewed
[5 lines not shown]
[AMDGPU] Pre-commit num_records of arbitrary width tests for LowerBufferFatPointers (#217137)
Add tests to ensure that the reasoning for whether an access can be
partially out of bounds and needs to be scalarized work correctly when
num_records has a width different from the hardware width.
AI disclosure: Claude generated these and I've looked at them
---
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
socket: Restore handling of IPPROTO_DIVERT
Python scripts which use divert sockets no longer work after commit
e967a2a03677; even if one patches socket() calls, getaddrlen() doesn't
work on divert sockets, needed to use recvfrom().
Restore compatibility when COMPAT_FREEBSD15 is defined.
Reviewed by: kib
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D59018
[NFC][SLP] Precommit test for fmul operand position in the FMA check (#218407)
SLP keeps a one-use fmul scalar so the backend can fuse it, but only
operand 0 of the fadd/fsub is checked. An fmul on the right hand side is
gathered into a vector fmul instead and the contraction is lost.
[MC][NFC] Store RegBitSet more compact (#218701)
Most register bit sets have their first register at a large offset,
causing a lot of 0 bytes to be stored in the RegBitSets. Avoid this by
storing the number of the lowest register in the MCRegisterClass. This
substantially reduces the size of the bit sets:
- AArch64: 35010 -> 1356
- AMDGPU: 1500754 -> 118320
- PowerPC: 2202 -> 610
- RISCV: 5700 -> 429
- X86: 2329 -> 927
This also opens up deduplication potential for the future -- in addition
to duplicates, a common pattern is a streak of the first N bits. To ease
future deduplication, store the maximum register offset instead of the
bitset size in bytes (so the bitset 0xff,0xff could absorb the bitsets
0xff,0x3f and 0x01).
Interfaces: Wireless: Devices - Migrate to MVC code, second phase, move settings from Interfaces into Wireless. closes https://github.com/opnsense/core/issues/10751
Move all settings from interface.XXX.wireless to wireless.clone and cleanup code referencing the old spot.
The console menu contained some, likely incomplete, code, which we will remove here as well, it doesn't feel very usefull trying to offer console configuration for wireless anyway.
Not all validations are being migrated, only the most relevant ones, which should be good enough.
Interfaces: Wireless: Devices - Migrate to MVC code, second phase, move settings from Interfaces into Wireless. for https://github.com/opnsense/core/issues/10751
Move all settings from interface.XXX.wireless to wireless.clone and cleanup code referencing the old spot.
console : seemed to show the parent interfaces, but without a useful implementation, removed it
