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

[Nikita Popov via llvm-commits]

nikic wrote:

> > I really wouldn't want to specify icmp as a provenance capturing operation.
> 
> So your position is that transforming `icmp (ptrtoint x), y` to `icmp x, (inttoptr y)` is actually not a valid transform because it throws away the provenance escape? But you're going to treat it as a TODO to fix later because it's unlikely to have a practical impact? I'm a little worried being more aggressive here might cause issues, but I don't have any specific example.

Basically, yes. (I don't think the icmp transform itself is invalid, but rather the DCE of the unused ptrtoint instruction, but the details aren't really relevant. If we need a bandaid for this, my intuition is that just not doing that icmp transform wouldn't be a particularly large loss.)

> > A possible alternative here would be to instead split off an extra address_is_null subset from address. That way we'd know that the address is only "captured" via null comparisons and could ignore this in transforms where the null comparison doesn't matter. Do you think that would make sense?
> 
> Propagating an additional bit is more complicated, unfortunately, but it might be the best solution. A lot of transforms can probably ignore the null capture (for example, if the pointer in question is produced by an inbounds gep).

Right. Anything AA-related is only going to care about provenance, and the transforms that care about address capture usually do some kind of allocation replacement (like e.g. call slot optimization and a few related ones) where we know in advance that we're replacing a non-null pointer with another non-null pointer, so null-pointer-only capture can be ignored.

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