[llvm] [LangRef] Mention allocation elision (PR #177592)

[Ralf Jung via llvm-commits]

================
@@ -2077,6 +2077,15 @@ For example:
     The first three options are mutually exclusive, and the remaining options
     describe more details of how the function behaves. The remaining options
     are invalid for "free"-type functions.
+
+    Calls to functions annotated with ``allockind`` are subject to allocation
+    elision: Calls to allocator functions can be removed, and the allocation
+    served from a virtual allocator instead. Notably, this is allowed even if
+    the allocator calls have side-effects.
+
+    If multiple allocation functions operate on the same allocation (for
+    example, an "alloc" followed by "free"), allocation elision is only allowed
+    if all involved functions have the same ``"alloc-family"``.
----------------
RalfJung wrote:

> Hm, I think that allowing creation of allocator calls out of thin air would be problematic for various reasons. For example, C malloc is not async signal safe, so synthesizing such a call inside a signal handler would be illegal.

Ah, nothing can ever be easy, can it...

So I guess we have to say something like, a `malloc` can non-deterministically obtain its memory from "elsewhere" (e.g. the stack; let's call this a "hidden" heap allocation), and it can also non-deterministically request more memory than given (to preempt a future `realloc`). A `realloc` on a hidden heap allocation is allowed and either returns a new hidden heap allocation or causes a regular `malloc`. A `free` on a hidden heap allocation is allowed and frees it "silently" without invoking the actual allocator.

https://github.com/llvm/llvm-project/pull/177592