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

Nikita Popov via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 11 00:42:34 PST 2026


================
@@ -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"``.
----------------
nikic wrote:

I've changed the wording to make the elision pairwise on alloc+free, where realloc can be converted into alloc+free for the purposes of elision. I think that should answer your question.

That is, if you have:
```
p1 = alloc N
; foo
p2 = realloc p1, P2, M
; bar
free p2
```
This can be converted to (omitting the copy from p1 to p2 to focus just on the allocation calls):
```
p1 = alloc N
; foo
p2 = alloc M
free p1
; bar
free p2
```
And then we can either do:
```
; foo
p2 = alloc M
; bar
free p2
```
Or:
```
p1 = alloc N
; foo
free p1
; bar
```

The variant
```
p2 = alloc max(N, M)
; foo
; bar
free p2
```
is not allowed a-priori -- and probably shouldn't be allowed in general, because the realloc might be a large allocation and `; foo` might be freeing a large allocation, so doing a larger allocation earlier may result in OOM. Allocation transforms should generally only remove OOMs, not introduce them. Of course, this optimization may still be performed if e.g. `; foo` is side-effect free so the move is not observable anyway.

I hope that clarifies things.

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


More information about the llvm-commits mailing list