[X86] Lower llvm.zeroize to a late clearing sequence

[claude]

Requested by Francesco Bertolaccini · Slack thread

Sixth patch in the stack, on top of #5. Closes trailofbits/vspells-ct-internal-notes#11.

llvm.zeroize had no expansion, so a function using it did not build. This routes it through both instruction selectors to a clearing sequence on x86-64.

What keeps the emitted sequence from being optimized away

Expanding the intrinsic into stores at selection time would make the guarantee depend on every later pass choosing not to remove them, and the region a clear covers is normally dead afterwards, which is exactly the shape a store-removing pass looks for.

So neither selector emits a store. Both emit ZEROIZE64, an X86 pseudo with no pattern and no memory operand, carrying hasSideEffects and mayStore. While it exists there is no store for anything to find: no analysis can attribute a write to it, so no pass can prove that write redundant, and the side-effect flag keeps it off the dead-code lists. X86ExpandPseudo turns it into movb $0, %al; rep;stosb in addPreSched2, after register allocation.

That is the whole argument, and it is structural rather than a matter of pass ordering luck: before the expansion there is no store to remove, and after it nothing remains in the pipeline that removes stores.

Entry points

Both are the hook each selector already has for an intrinsic that needs custom handling rather than a generic call:

• SelectionDAG: LowerINTRINSIC_W_CHAIN, reached from LowerOperation for ISD::INTRINSIC_VOID, which X86 already marks Custom. SelectionDAGBuilder builds that node for any intrinsic it does not handle itself.
• GlobalISel: X86LegalizerInfo::legalizeIntrinsic, which until now accepted every intrinsic unchanged.

Each copies the destination and the count into %rdi and %rcx and emits the pseudo, so the two selectors produce the same machine code.

Tests

llvm/test/CodeGen/X86/zeroize.ll runs both selectors (-global-isel -global-isel-abort=1 for the second) over dynamic, constant and narrow lengths, a clear followed by a store covering the same bytes, two identical clears, a clear of an alloca that never escapes and dies at the return, and a clear immediately before lifetime.end. Each of the first two is paired with the equivalent plain store, which the backend does remove, so the test pins the difference rather than only that some instructions came out.

llvm/test/CodeGen/X86/zeroize-expand-late.ll pins the lateness directly, for both selectors: what each handed over is the pseudo, it is still the pseudo after register allocation (-stop-before=x86-expand-pseudo), and the write appears only in the expansion.

Confirmed load-bearing by breaking each of the three pieces separately (SelectionDAG lowering, GlobalISel lowering, pseudo expansion) and checking the tests fail each time.

Scope

x86-64 (LP64) only. 32-bit x86 still reports the intrinsic as unlowered, as it did before this patch, and sequences for other targets are separate work.

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.}