[IR] Add !sensitive metadata for sensitive stack objects

[claude]

Requested by Francesco Bertolaccini · Slack thread

Register a fixed metadata kind, MD_sensitive with ID 56, marking an alloca
whose contents should not be left readable in the stack frame once the function
is done with them. The metadata is only used as a flag: its presence on the
alloca is the entire signal and the node must be empty, with the contents of
the node reserved for future use.

%round_keys = alloca [176 x i8], align 16, !sensitive !0

!0 = !{}

The marked objects are what the "sensitive" mode of the "zeroize-stack"
attribute clears, so the LangRef entry is written around the direction of the
fallback between the two, and the attribute entry now cross-references it
instead of referring to "sensitivity metadata" without naming it. The metadata
buys precision and is not itself part of the guarantee, which LangRef spells out
as rules a transform has to respect: dropping the metadata is always permitted,
and where the marked set has stopped describing the frame — a marked object
split, merged, replaced or promoted without the metadata following — the
response is to clear more, at the limit every stack slot the function used, never
to clear less. Attaching it to an object that was not marked before is likewise
permitted and can only widen what is cleared. Absence of the metadata is not a
statement that an object is insensitive, so a transform may not shrink the set
of objects a function clears on the strength of what is or is not marked.

What makes losing the metadata safe is the floor the mode already has: it clears
every frame object whose contents cannot be traced back to a source-level object
— spill slots, the callee-save area, alignment padding — whether or not anything
is marked. Those are exactly the places a copy of marked data can land with
nothing recording where it came from.

Parsing, printing and bitcode serialization of metadata attachments are generic,
so nothing in the parser or the bitcode reader and writer needed changing;
registering the kind is what gives consumers a fixed ID to look the attachment up
by. llvm/test/Assembler/sensitive-metadata.ll covers the textual and bitcode
round-trips, alongside the comparable per-kind assembler tests
associated-metadata.ll and noalias-addrspace-md.ll.

No pass or backend reads the metadata yet, and nothing here changes the
behaviour of any existing pass. Which transforms should be taught to carry the
metadata across the objects they create is scoped separately as
trailofbits/vspells-ct-internal-notes#13; LangRef says that propagation is a
question of precision rather than of correctness, which is what makes it safe to
defer.

The spellings !sensitive and "zeroize-stack" are recommendations still
awaiting sign-off on trailofbits/vspells-ct-internal-notes#64, not ratified
names.

Third change in the wave-1 stack, on top of zeroize-intrinsic. Implements
trailofbits/vspells-ct-internal-notes#12.

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