[Sparc] Fix 32-bit return for values demoted to sret (#240041)
On 32-bit SPARC, a return value that does not fit in the return
registers (e.g. fp128, or a struct larger than six i32s) is demoted
to a hidden sret argument by the generic call lowering. The caller
side keys off the sret argument flags and correctly emits the
struct-return sequence with an unimp after the call. The callee side,
however, only checked hasStructRetAttr() on the IR function, which
is false for a demoted return. As a result the callee neither copied
the sret pointer to %i0 nor returned past the unimp, so control
landed on the unimp in the caller and trapped.
Check the lowered sret argument / SRetReturnReg instead of the IR
attribute so demoted returns are handled the same way as an
explicit sret parameter.
IsEligibleForTailCallOptimization() had the same problem: a caller
whose return value was demoted to sret has no sret attribute, and the
check was skipped entirely when the callee has no arguments. In both
[7 lines not shown]
[X86] Skip debug instructions when adjusting the stack with pops (#229392)
At `minsize`, X86 can discard one or two stack slots after a call using
one-byte `popl` instructions instead of a larger `addl` instruction.
Adding debug information could prevent this optimization and change the
ordinary generated code.
`eliminateCallFramePseudoInstr()` removes the call-frame adjustment
pseudo and advances the cleanup insertion point past debug instructions.
`adjustStackWithPops()` then used `std::prev()` to inspect the preceding
instruction. If a `DBG_VALUE` appeared between the call and the
insertion point, it saw the debug instruction instead of the call and
rejected the pop-based cleanup.
Use `prev_nodbg()` to find the preceding call while preserving the
existing pseudo-probe behavior. The regression test places a debug value
after a call and verifies that the two-slot cleanup still uses two
`popl` instructions rather than `addl $8, %esp`.
The regression check fails before this change and passes afterward. The
complete X86 CodeGen test suite also passes.
RuntimeLibcalls: Add missing attributes to libm libcalls
Add the function and memory attributes inferLibFuncAttributes would
give the scalar libm functions.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
RuntimeLibcalls: Add missing attributes to memory and allocator libcalls (#240735)
Add the attributes inferLibFuncAttributes would give these functions.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[DebugInfo][DwarfDebug] Ignore lexical blocks of function-local entities inside type units (#241519)
DwarfDebug was crashing when attempting to emit a type unit for a
function-local type within a lexical block. This happened because
DwarfTypeUnit doesn't handle lexical blocks: requesting a context DIE
for a local entity (local type) in scope of a lexical block fell back to
`DIE::get()` call, which returns null (test example:
https://godbolt.org/z/qfodf7cqc).
DwarfTypeUnit now skips lexical block scopes when looking up the context
DIE of a local entity. As a result, local entities are emitted as direct
children of their DW_TAG_subprogram DIEs.
In IR, lexical blocks appear within the scopes of definition
subprograms. DwarfTypeUnit never populates definition subprograms with
attributes (this is done only by DwarfCompileUnit). Therefore, this
patch should not introduce any regressions compared to the existing
behavior.
icp: call armv7 SHA2 asm through C wrappers
sha256_armv7_impl and sha512_armv7_impl stored the assembly entry
points zfs_sha256_block_armv7() and zfs_sha512_block_armv7() directly
in their ops tables. Assembly functions carry no kCFI type hash, so on
an arm64 or arm kernel built with CONFIG_CFI every indirect call
through ops->transform traps:
CFI failure at SHA2Update+0xe0/0x250 [zfs]
(target: zfs_sha256_block_armv7+0x0/0xe40 [zfs]; expected type: ...)
On arm64 armv7 is typically the fastest SHA-512 implementation, as
NEON is unavailable to zfs, so this hits every sha512 checksum.
Call them from C wrappers, as the x64 implementation does. No
kfpu_begin() is needed, as this code does not use NEON.
Tested on Linux 7.3 arm64 with CONFIG_CFI=y and CONFIG_CFI_PERMISSIVE=y
in QEMU: before, loading zfs.ko logged 1064 CFI failures from the
checksum benchmark; after, none, and both armv7 implementations
[6 lines not shown]
zstdcheck: allow __cfi_ prefixed symbols
On kernels built with CONFIG_CFI, clang emits a global __cfi_<func>
symbol for each function's type-hash preamble, just as
CONFIG_CALL_PADDING emits __pfx_<func>. check-zstd-symbols already
accepts __pfx_zfs_*, but reports every __cfi_zfs_* symbol as an
unprefixed zstd symbol, so make checkstyle fails on such kernels.
Accept __cfi_zfs_* as well.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
Signed-off-by: Cytops <cyridge at proton.me>
Closes #19562
icp: call x86_64 AES asm through C wrappers
aes_x86_64_impl stored the assembly entry points aes_encrypt_amd64()
and aes_decrypt_amd64() directly in its ops table. Assembly functions
carry no kCFI type hash, so on a kernel built with CONFIG_CFI every
indirect call through ops->encrypt/decrypt traps:
CFI failure at aes_encrypt_block+0xf4/0x120 [zfs]
(target: aes_encrypt_amd64+0x0/0x9f0 [zfs]; expected type: ...)
The path is used when AES-NI is unavailable or icp_aes_impl=x86_64.
Call them from C wrappers, as the SHA2 and BLAKE3 code already does.
Tested on Linux 7.3 with CONFIG_CFI=y and CONFIG_CFI_PERMISSIVE=y in
a VM with icp_aes_impl=x86_64 and icp_gcm_impl=generic: before, ~47k
CFI failures during encrypted dataset I/O; after, none, and
create/write/scrub/export/import/load-key of AES-GCM and AES-CCM
datasets succeeds with no pool errors.
[4 lines not shown]
Attributor: Check for a fixpoint state with a single virtual call (#241576)
Checking whether an abstract attribute is at a fixpoint took two virtual
calls, getState and isAtFixpoint. Add isStateAtFixpoint, which
StateWrapper implements with a direct call, and use it in the fixpoint
iteration.
attributor-light instruction counts (callgrind): -0.62% median over 68
llvm-test-suite TUs, the full attributor -0.70%.
Co-authored-by: Johannes Doerfert <jdoerfert.llvm at gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[BoundsSafety] Handle the counted_by family as a type attribute (non-late parsing only)
counted_by / sized_by (and their _or_null variants) were handled as
declaration-position attributes through handleCountedByAttrField.
Build the type during type construction instead, and handle them properly
as type-position attributes. Building the node in type position also
allows the new way of late-parsing type attributes: create a type node in
place and fill it in once late parsing is done. That will be enabled in
follow-up commits.
User-visible changes:
- [[clang::counted_by]] on a field's pointer declarator, as in
`int * [[clang::counted_by(n)]] p;`, is now accepted instead of being
rejected as "cannot be applied to types". It's still rejected on a
non-field declarator chunk.
- A counted_by-family attribute on a nested pointer, as in
`int *__counted_by(n) *pp;`, is now rejected. It was previously
applied to the outer pointer instead.
[12 lines not shown]
