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

[Ralf Jung via llvm-commits]

================
@@ -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:

> But you currently forbid shrinking?

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

> I agree munmapping is problematic; overlapping objects would be hard to reason about. There are potentially useful "holes", though: mprotecting a page from a continuous range for a JIT would be a hole in the sense that reads aren't legal.

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

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