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

Eli Friedman via llvm-commits llvm-commits at lists.llvm.org
Wed May 28 10:55:08 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.
----------------
efriedma-quic wrote:

> Yeah but I'd like to allow it in the future -- it seems more important to me than growing to the left.

Hmm, okay.

> I don't think an mprotect causing reads and writes to trap is fundamentally different from munmap for this purpose, or is it?

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.

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


More information about the llvm-commits mailing list