antoniofrighetto wrote: > > `-fassume-sane-operator-new` seems to make a statement about operator new > > only, > > `-fassume-sane-operator-new` marks the new operator noalias, which is > basically saying it creates provenance. This is the exact counterpart: delete > destroys that provenance.
I see that now, thanks for the clarification. > `%p = ptr @llvm.provenance.alloc(ptr %p_orig, i64 %size)` returns a pointer > `%p` with fresh provenance for `%size` bytes starting at `%p_orig`. At the > same time, access permissions for this region are removed from `%p_orig` > (including from any "related" pointers). > > `%p_orig_new = ptr @llvm.provenance.dealloc(ptr %p)` removes access > permissions of `%p`, restores access permissions on `%p_orig` and returns a > pointer with the same provenance as `%p_orig`. Partially related, one thing I had been previously wondering about, assuming realloc may be part of the model, was whether a `resize` intrinsic for in-place allocations could be envisioned (which would transfer the provenance to the shrunk pointer), but I guess a realloc is conceptually pretty much always a dealloc + alloc. > To handle asymmetrically inlined allocators fully correctly, we probably > actually need to materialize intrinsics like these for the operator new > return / operator delete argument. Some allocators happen to store metadata inside the freed chunk, which, IIRC, requires dereferencing the freed block. Say allocator internals get inlined as part of `operator delete`, I assume such materialized intrinsics would aspire to act, to some extent, as lifetime start / end of the allocation / deallocation, except that they would say which pointer operations are allowed on which memory (rather than saying which memory is live or dead). https://github.com/llvm/llvm-project/pull/198202 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
