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

Nikita Popov via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 11 03:58:31 PST 2026


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

>From b2f9fe0e2e79491774feb209fc758feb7cf703d3 Mon Sep 17 00:00:00 2001
From: Nikita Popov <npopov at redhat.com>
Date: Fri, 23 Jan 2026 15:09:20 +0100
Subject: [PATCH 1/6] [LangRef] Mention allocation elision

allockind / alloc-family enable allocation elision, but this was
not previously mentioned by LangRef. Related discussion:

https://discourse.llvm.org/t/rfc-clarifying-semantic-assumptions-for-custom-allocators/89469
---
 llvm/docs/LangRef.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 00a4a00c5bf95..55ae958fb78e5 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -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"``.
 ``"alloc-variant-zeroed"="FUNCTION"``
     This attribute indicates that another function is equivalent to an allocator function,
     but returns zeroed memory. The function must have "zeroed" allocation behavior,

>From 170e43f5b9a6df0386445c5b71aa94f088a88aea Mon Sep 17 00:00:00 2001
From: Nikita Popov <npopov at redhat.com>
Date: Mon, 26 Jan 2026 10:21:19 +0100
Subject: [PATCH 2/6] Mention that all or none have to be elided

---
 llvm/docs/LangRef.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 55ae958fb78e5..7db68b5acbff1 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -2085,7 +2085,8 @@ For example:
 
     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"``.
+    if all involved functions have the same ``"alloc-family"``. In this case,
+    either all operations have to be elided or none of them.
 ``"alloc-variant-zeroed"="FUNCTION"``
     This attribute indicates that another function is equivalent to an allocator function,
     but returns zeroed memory. The function must have "zeroed" allocation behavior,

>From c0f5a78f7e926014fef2d7fe3c5414e782fb4af1 Mon Sep 17 00:00:00 2001
From: Nikita Popov <npopov at redhat.com>
Date: Mon, 26 Jan 2026 10:34:35 +0100
Subject: [PATCH 3/6] Explicitly clarify allowed transforms

---
 llvm/docs/LangRef.rst | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 7db68b5acbff1..0d9fb66064ccd 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -2085,8 +2085,14 @@ For example:
 
     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"``. In this case,
-    either all operations have to be elided or none of them.
+    if all involved functions have the same ``"alloc-family"``. The following
+    transforms can be performed, or combinations thereof:
+
+    * An "alloc" that is leaked (no "free"/"realloc") can be elided.
+    * An "alloc" and "free" pair can be elided.
+    * A "realloc" and "free" pair can be converted into a "free" of the original
+      allocation.
+    * An "alloc" and "realloc" pair can be converted into an "alloc".
 ``"alloc-variant-zeroed"="FUNCTION"``
     This attribute indicates that another function is equivalent to an allocator function,
     but returns zeroed memory. The function must have "zeroed" allocation behavior,

>From 989d9ea2265f1bc0402b114efcf2c9f9cec25a4b Mon Sep 17 00:00:00 2001
From: Nikita Popov <npopov at redhat.com>
Date: Wed, 11 Feb 2026 09:31:13 +0100
Subject: [PATCH 4/6] Clarify realloc interaction

---
 llvm/docs/LangRef.rst | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 0d9fb66064ccd..5c7cf05f2f4b1 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -2083,16 +2083,11 @@ For example:
     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"``. The following
-    transforms can be performed, or combinations thereof:
-
-    * An "alloc" that is leaked (no "free"/"realloc") can be elided.
-    * An "alloc" and "free" pair can be elided.
-    * A "realloc" and "free" pair can be converted into a "free" of the original
-      allocation.
-    * An "alloc" and "realloc" pair can be converted into an "alloc".
+    If multiple allocation functions operate on the same allocation,
+    allocation elision is only allowed for pairs of "alloc" and "free" with the
+    same ``"alloc-family"`` attribute. For this purpose, a "realloc" call may
+    be decomposed into "alloc" and "free" operations, as long as at least one
+    of them will be elided.
 ``"alloc-variant-zeroed"="FUNCTION"``
     This attribute indicates that another function is equivalent to an allocator function,
     but returns zeroed memory. The function must have "zeroed" allocation behavior,

>From 5a305f7844dc4a3b5c9f82c60e0383bff87a7f4e Mon Sep 17 00:00:00 2001
From: Nikita Popov <npopov at redhat.com>
Date: Wed, 11 Feb 2026 09:34:56 +0100
Subject: [PATCH 5/6] Explicitly mention non-determinism

---
 llvm/docs/LangRef.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 5c7cf05f2f4b1..a8113358754fa 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -2081,7 +2081,9 @@ For example:
     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.
+    the allocator calls have side-effects. In other words, for each allocation
+    there there is a non-deterministic choice between calling the allocator as
+    usual, or using a virtual, side-effect-free allocator instead.
 
     If multiple allocation functions operate on the same allocation,
     allocation elision is only allowed for pairs of "alloc" and "free" with the

>From b49317931f94b715cac049ee37e78edd268f35f3 Mon Sep 17 00:00:00 2001
From: Nikita Popov <npopov at redhat.com>
Date: Wed, 11 Feb 2026 12:58:13 +0100
Subject: [PATCH 6/6] typo

---
 llvm/docs/LangRef.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index a8113358754fa..12030ef8255b9 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -2082,8 +2082,8 @@ For example:
     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. In other words, for each allocation
-    there there is a non-deterministic choice between calling the allocator as
-    usual, or using a virtual, side-effect-free allocator instead.
+    there is a non-deterministic choice between calling the allocator as usual,
+    or using a virtual, side-effect-free allocator instead.
 
     If multiple allocation functions operate on the same allocation,
     allocation elision is only allowed for pairs of "alloc" and "free" with the



More information about the llvm-commits mailing list