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

Eli Friedman via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 25 14:29:04 PST 2024


efriedma-quic 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.

> 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).

Another alternative is to introduce an inbounds bit on icmp.

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


More information about the llvm-commits mailing list