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

Eli Friedman via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 22 14:38:04 PST 2024


efriedma-quic wrote:

I'm not quite sure about the statement that icmp doesn't capture provenance... I mean, take something like the following:

````
void f(int*x) {
  if ((size_t)x == 0x11111111)
    *(int*)0x11111111 = 10;
}
````

Your phrasing implies this code is UB.  Which... I'm not sure whether it's what you want, but it's a change to the underlying semantics.  (LLVM optimizations currently convert icmp of a ptrtoint to an icmp of the underlying pointer.)

In the interest of making sure there aren't any surprises here, maybe we should say that this is a provenance capture?   (If you're planning to introduce a non-provenance-capturing ptrtoint, it can be used to express a non-capturing icmp.)

--------

I think it makes sense to consider a null-comparison involving dereferenceable_or_null to be non-capturing, but I think we need to tighten the phrasing on dereferenceable_or_null to actually make that true.  There isn't really anything stopping someone from just doing an out-of-bounds gep where the result happens to be null... at which point, you've captured the address.  I think we need some statement indicating the "null" in dereferenceable_or_null has to be a true null, not the result of an out-of-bounds gep.

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


More information about the llvm-commits mailing list