also point about adding new primitives

diff --git a/personal/_posts/2026-03-13-inline-asm.md b/personal/_posts/2026-03-13-inline-asm.md
index ea5ef483bb60f2c49298bf66af8ff7ca18d81211..d66d8f32d1cbc0ce6f2437ff2ad93d80f6645b34 100644 (file)
--- a/personal/_posts/2026-03-13-inline-asm.md
+++ b/personal/_posts/2026-03-13-inline-asm.md
@@ -281,8 +281,10 @@ In some cases, however, there are no obvious miscompilations.
 And indeed, if we knew exactly which universal properties of Rust programs the compiler relies on, we could allow inline asm code that satisfies all those universal properties, even if it has no story which can be expressed in Rust source code.
 Unfortunately, this approach would require us to commit to the full set of universal properties the compiler may ever use.
 If we discover a new universal property tomorrow, we cannot use it since there might be an inline asm block for which the universal property does not hold.
+
 This is why I am proposing to take the conservative approach:
-only allow inline asm blocks that are obviously compatible with all universal properties of actual Rust code, because their story can be expressed as actual Rust code!
+only allow inline asm blocks that are obviously compatible with all universal properties of actual Rust code, because their story can be expressed as actual Rust code.
+If there is an operation we want to allow that currently has no valid story, we should just [add](https://github.com/rust-lang/rfcs/pull/3700) a [new language operation](https://github.com/rust-lang/rfcs/pull/3605), which corresponds to officially blessing that operation as one the compiler will keep respecting.
 
 [^noopt]: This assumes that we do not want to sacrifice the optimizations in question. Since inline assembly could hide inside any function call, this typically becomes a language-wide tradeoff: either we forbid such inline asm blocks, or we cannot do the optimization even in pure Rust code.