[RISCV] Don't require specific extensions to use altfmt with vset(i)vli. (#202458)
The list of extensions that use altfmt is increasing and is becoming
unsustainable. The likelihood of the bit being repurposed is decreasing
with each new use. Let's just allow it unconditionally.
There is some risk here since all of these extensions are still
unratified and experimental so it could be that all of these extensions
get redefined so that this bit doesn't become altfmt. But I think that's
unlikely.
net80211: create IEEE80211_KEYBUF_128_SIZE / IEEE80211_MICBUF_128_SIZE
The IEEE80211_KEYBUF_SIZE and IEEE80211_MICBUF_SIZE are sprinkled
throughout the net80211 stack, ioctl API and drivers. This makes it
challenging to (eventually) up IEEE80211_KEYBUF_SIZE to support 256 /
384 bit encryption as, well, it'll break every single driver and the
ioctl API in doing so.
So as part of this, let's start to separate out the current key/mic
buffer size from what drivers and the ioctl layer are using.
Drivers especially shouldn't be using these definitions as their
key sizes are hardware / firmware API limits, not net80211 limits.
Ideally drivers would define their own key buffer / mic buffer
sizes and only copy in keys up to that length (and fail keys
that are too large) but the current net80211 API isn't there yet.
This doesn't yet change what defines / buffer sizes are used in the
ioctl layer. I'm going to plan out some subsequent work to
separate out those defines and ioctl APIs so they maintain using
[4 lines not shown]
[libc++][span][test] Various cleanups for <span> tests (#202319)
This patch does:
- Simplify some test implementations
- Polish comments and synopsis
---------
Co-authored-by: A. Jiang <de34 at live.cn>
[BPF] Emit ABI-accurate BTF prototypes for DW_CC_nocall (#198426)
DW_CC_nocall subprograms can end up with an optimized IR signature that no
longer matches the original source-level DISubroutineType. Dead argument
elimination may drop source parameters, and the return value may be
removed entirely, while the debug type still describes the original
prototype. In that case BTFDebug emits a FUNC_PROTO that no longer
matches the real BPF ABI.
Teach BTFDebug to derive a filtered FUNC_PROTO for nocall functions.
Detecting surviving arguments (collectNocallEntryArgRegs):
Scan all DBG_VALUE instructions in the entry block while tracking which
registers have been redefined by non-debug instructions:
- A DBG_VALUE whose register has not been redefined records a
register-passed argument (R1-R5 at function entry).
- A DBG_VALUE whose register was most recently loaded via LDD $r11,
[35 lines not shown]
Revert "[NVPTX] Support lowering of `(l)lround`" (#202500)
Reverts llvm/llvm-project#183901
Looks like using removeFromUseLists from Transforms doesn’t work in
certain configurations.
[LLDB] Fix DW_OP_implicit_value GetOpcodeDataSize() error (#201344)
LLDB does not handle `DW_OP_implicit_value` right, causing a "cannot get
opcode data size for Unknown DW_OP constant" error when LLDB parses
location expressions containing this opcode.
`DW_OP_implicit_value` takes two operands: a ULEB128-encoded length
followed by a byte sequence of that length. The current
`GetOpcodeDataSize` implementation has no case for this opcode, only
skip. This prevents LLDB from correctly determining opcode boundaries
when scanning multi-operation location expressions.
From DWARFv5
> The DW_OP_implicit_value operation specifies an immediate value using
two operands: an unsigned LEB128 length, followed by a sequence of bytes
of the given length that contain the value.
Although the evaluation path (`DWARFExpression::Evaluate`) handles this
opcode correctly and produces the right result, the validation/parsing
path emits a confusing error message to the user.
misc/zeroclaw: newport
ZeroClaw is a fast, small, 100% Rust AI assistant / agent CLI (model
providers, multi-agent workflows, chat channels, and a local gateway).
WWW: https://github.com/zeroclaw-labs/zeroclaw
PR: 295837
[NVPTX] Support lowering of `(l)lround` (#183901)
These intrinsics should have the same semantics as libm `round`, but
with an integer return type. Nits appreciated.
Fixes #182378
Reland [RISCV] Prefer SP over FP for frame index access when offset fits within compressed immediate range. (#201541)
Before this change, we would use fp/s0/x8 for most stack accesses when
frame pointers were present. This is an over-approximation when a
stack slot is reachable from both SP and FP with no scalable offset.
This patch replaces the unconditional getFrameRegister() call in
getFrameIndexReference with an explicit register selection decision
tree.
When both SP and FP are available (no stack realignment, no
variable-sized objects), prefer SP if the SP-relative offset fits in
the compressed instruction immediate range (<=252 for RV32, <=504 for
RV64). This enables compression for sp-relative instructions to
c.swsp/c.lwsp (RV32) and c.sdsp/c.ldsp (RV64) thereby reducing code
size.
The SP preference is guarded by hasReservedCallFrame(MF) to ensure SP
is stable throughout the function body. This is necessary because
[9 lines not shown]
switch nfs_getreq() to nfsd_adv()
from miod@ ok jsg@
This round of commits was prompted by a double-free report
from Andrew Griffiths at Calif.
server nfs request mbuf pointers were stored in two structs:
nmi_mrep in struct nfsm_info
nd_mrep in struct nfsrv_descript
but only set to NULL after m_freem() in nmi_mrep
This problem is avoided by removing the use of struct nfsm_info
in the server paths and passing struct nfsrv_descript to
new versions of the nfsm functions.
