[llvm] [IR] Introduce intrinsics to model allocator provenance semantics (PR #228048)

[Antonio Frighetto via llvm-commits]

================
@@ -2148,10 +2155,29 @@ define void @f() "no-sse" { ... }
       zeroed.
     * "aligned": the function returns memory aligned according to the
       `allocalign` parameter.
+    * "address_unpredictable": the address of the returned allocation cannot
+      be predicted by the caller. Comparisons of the address with pointers not
+      derived from the allocation may assume the two are unequal, provided this
+      is done consistently for all observations of the address. This does not
+      hold for allocators that return storage at an address that is derived from
+      their inputs (more at {ref}`llvm.provenance.alloc <int_provenance_alloc>`).
+    * "alloc_disjoint": the returned allocation does not overlap with storage
+      of allocas, global variables, `byval` arguments, or other allocations.
+      This only holds for top-level allocators which are not nested within
+      another allocator.
----------------
antoniofrighetto wrote:

Thanks for sharing! Perhaps worth noting that my understanding of the issue is that this has fundamentally long existed since LLVM has folded allocations (likely since the early days), and admittedly, the example provided is somewhat contrived, as already noted.

Wrt the interaction with it, I'm not entirely sure how `alloc_disjoint` could be directly beneficial here. The Rust frontend might annotate some top-level allocators with the attribute, letting LLVM know that the allocation doesn't overlap anything else, but only as long as the allocation succeeds. Except that, LLVM would continue folding the allocation away while treating it as though it had succeeded. So, LLVM should probably start forbidding eliding `alloc_disjoint` allocations, which doesn't sound that great, does it?

Though, thinking about it more, possibly the other way around could work out better, i.e., an allocator marked noalias + allockind("alloc") without alloc_disjoint might, to some extent, satisfy the semantics @RalfJung was hinting at, i.e., if I'm understanding correctly, a model where allocations may overlap in address (and provenance would be what disambiguate them).

(That said, by my reckoning, which might well be off track, it sounds a bit like this might be ultimately more for the Rust operational semantics team to settle whether `&mut` disjointness is an absolute invariant or a conditional one.)

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