[CodeGen] Ask the target whether it can clear registers or the stack

[claude]

Requested by Francesco Bertolaccini · Slack thread

A request to clear call-used registers is dispatched through
emitZeroCallUsedRegs, whose default body is empty. A target that has not
implemented it therefore compiles the request into nothing at all, and nothing
says so: the caller asked for the registers to be destroyed, the object file
leaves them holding what was in them, and the only way to find out is to read
the disassembly. ARM32 is the live case. The driver refuses the command-line
flag there through a hard-coded list of triples, but the function attribute
that flag turns into is accepted, carried through the whole pipeline, and
dropped in the frame lowering, so anything that sets the attribute directly,
including LTO and inlining of code compiled elsewhere, silently gets nothing.

Add a capability query the target answers instead of inferring support from an
emission that may do nothing. supportsZeroCallUsedRegs defaults to false, so a
target is unsupported until it says otherwise, and prologue-epilogue insertion
asks before computing what to clear: a target that answers false gets a
diagnostic and no code, rather than no diagnostic and no code. The three
targets that implement the emission today, X86, AArch64 and RISCV, answer true,
which is what the driver's triple list already assumed, so no target changes
what it generates.

supportsZeroizeStack is the same query for the "zeroize-stack" attribute, and
today every target answers false, because none of them clears the frame yet.
That attribute has had no backend consumer at all since it was added, which is
the same silence in a worse form, so it now reports itself as unsupported
everywhere until an implementation exists.

DiagnosticInfoUnsupported is what the backend already uses to refuse a request
it cannot compile, including in frame lowering, where RISCV reports a reserved
stack or frame pointer through it. It names the function, is an error rather
than a warning, and leaves llc exiting non-zero, which is what fails closed
means here.

The scope is the query surface and the refusal. Clearing the stack is
trailofbits/vspells-ct-internal-notes#26 and the set of registers to clear is
unchanged, on trailofbits/vspells-ct-internal-notes#27. The frontend
diagnostic that replaces the driver's triple list is
trailofbits/vspells-ct-internal-notes#67, which will consult these queries.
The names are recommendations awaiting sign-off on
trailofbits/vspells-ct-internal-notes#64.

This is trailofbits/vspells-ct-internal-notes#23, under the umbrella
trailofbits/vspells-ct-internal-notes#17.

AI tool use

This pull request contains AI-generated content. It was prepared with the assistance of Claude Code; the contributor has reviewed the generated code and text, is the author of the contribution, and is accountable for it, per the LLVM AI Tool Use Policy.

---

Generated by Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[claude]

A full check-llvm run at the tip of the stack shows this branch is where llvm/test/Transforms/Inline/zeroize-stack-lto.ll starts failing. It passes at PR #6 and at the upstream base 5bff54f44e.

The cause is the new "not supported by this target" diagnostic added here at PrologEpilogInserter.cpp:1804, which fires on a test that PR #4 added. Neither patch is wrong on its own, and neither branch's own test run catches it — the failure only appears once both are in the same tree.

Build: LLVM_TARGETS_TO_BUILD="X86;ARM;AArch64;RISCV", Release, assertions off. Totals at the tip of the stack were 54950 passed / 5 failed, with the gtest unit suite clean at 11707 / 0.

---

Generated by Claude Code