nikic wrote: The way I would model allocator provenance goes something like this:
`%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`. That is, allocators form a provenance tree where an allocation adds a new leaf, and deallocation recovers the provenance of the parent. This ensures that free lists work correctly. To handle asymmetrically inlined allocators fully correctly, we probably actually need to materialize intrinsics like these for the operator new return / operator delete argument. > I'm a little worried about adding provenance annotations when we haven't > nailed this down yet. Especially with -fno-assume-sane-operator-new, since > that's the only escape hatch we have at the moment. Thinking about this again, making this part of `-fassume-sane-operator-new` probably makes sense, because the `captures(address)` on `operator delete` is kind of the dual of `noalias` on `operator new`, and we only add the latter for sane operator new. https://github.com/llvm/llvm-project/pull/198202 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
