efriedma-quic wrote: > `%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`.
And the argument of the intrinsic is `captures(address)`? That directly follows from the operand to `operator delete` itself being `captures(address)`. I guess that's a consistent model, but maybe a little mind-bending for anyone who hasn't thought about it... > To handle asymmetrically inlined allocators fully correctly, we probably > actually need to materialize intrinsics like these for the operator new > return / operator delete argument. Yes, this makes sense. > `-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. Under the model where new doesn't create provenance, delete also doesn't destroy provenance, so it has to capture it. https://github.com/llvm/llvm-project/pull/198202 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
