[llvm] LangRef: allocated objects can grow (PR #141338)

Ralf Jung via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 10 07:05:36 PDT 2025


================
@@ -3327,6 +3327,19 @@ behavior is undefined:
 -  the size of all allocated objects must be non-negative and not exceed the
    largest signed integer that fits into the index type.
 
+Allocated objects that are created with operations recognized by LLVM (such as
+:ref:`alloca <i_alloca>`, heap allocation functions marked as such, and global
+variables) may *not* change their size. (``realloc``-style operations do not
+change the size of an existing allocated object; instead, they create a new
+allocated object. Even if the object is at the same location as the old one, old
+pointers cannot be used to access this new object.) However, allocated objects
+can also be created by means not recognized by LLVM, e.g. by directly calling
+``mmap``. Those allocated objects are allowed to grow to the right (i.e.,
+keeping the same base address, but increasing their size) while maintaining the
+validity of existing pointers, as long as they always satisfy the properties
+described above. Currently, allocated objects are not permitted to grow to the
+left or to shrink, nor can they have holes.
----------------
RalfJung wrote:

> Alias analysis doesn't really care if an object is actually accessible at the moment; it just cares we don't overlap with some other object. Dereferenceability is only relevant if you want to do speculative loads. So you can separate dereferenceability from the rest of the properties of an allocation.

Right, but my example above used dereferenceability. So it is equally an example for why mprotect on the middle of an allocation could be problematic.

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


More information about the llvm-commits mailing list