[llvm] [IR] Introduce captures attribute (PR #116990)

[Nikita Popov via llvm-commits]

nikic wrote:

> Do we want to say something about null pointers? Not sure which way you want to go, but we currently have some special handling for null in capture tracking.

This is a good question. Generally speaking, comparison with null still counts as an address capture, just like any other comparison. This is because `p == q` is equivalent to `ptradd (p, -q) == null`.

The caveat here is that is that we have two special cases:

 * We don't count comparison of an allocation (in the sense of `malloc`) with null as a capture.
 * We don't count a comparison of dereferenceable_or_null with null as a capture.

So maybe this could be generalized like this for the purpose of LangRef?

> A comparison of a pointer that is known to be either null or in bounds of an allocated object (e.g. the return value of malloc), with a null pointer, is not considered an address capture.

-----

> Do we need to say anything about fences? (ref #64188)

We probably should, but I don't want to do that as part of this change, as this would also require implementation changes that I'm not sure how to do. My understand here is that (assuming this will not get fixed on the level of the memory model) fences only affect the notion of "captures before" by saying that if there is a fence (possibly behind a call) and the pointer is later captured, then the capture already occurs at the point of the fence. This is not something that really integrates into current CaptureTracking, which is based on following def-use chains, so we never see the fence.

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