[llvm] [LangRef] Specify icmp on pointers to only compare address (PR #163936)

[Alexander Richardson via llvm-commits]

arichardson wrote:

> The LangRef changes look fine to me, but I don't think I agree with most of the motivation:
> 
> > For inequality comparisons, this is really the only sensible semantics. Relational comparison of address and metadata bits as a single integer is generally meaningless (unless the metadata bits are equal).
> 
> For ordered comparisons, the address is the only thing that makes sense, but equality typically implies substitutability. We need to be careful that blocks reachable from a branch on `icmp eq %a, %b` don't assume that `%a` can substitute `%b`.

This should already be the case in LLVM and any optimization that makes this assumption without checking that `%a` and `%b` have the same provenance is incorrect.

> > This matches (as far as I understand) the behavior of existing CHERI implementations.
> 
> This is currently the behaviour of CHERI C/C++. As we've had more people trying to write these dialects, we've found that this is the number one source of friction. In CHERIoT, our C++ wrapper type around a CHERI capability uses exact (all bits including tag) and we have found from user feedback that this is a more understandable behaviour. I would like to change that behaviour, as it's also strictly not a compliant implementation of C++ as of C++20, which explicitly requires equality to respect the substitution principle.
> 

This would be great but I was not able to spot this in the draft spec, all I found was https://eel.is/c++draft/expr.eq which states that comparing past-the-end pointers is unspecified, but pointers with the same address compare equal.

> > LLVM can only reason about the address bits. These semantics allow pointers with non-address bits to receive essentially the same comparison optimization support as ordinary pointers.
> 
> Such optimisations are almost certainly unsound. Comparing only the address permits substitution with address-only pointers (modulo provenance-based alias analysis). It does not on CHERI.

I don't believe substitution is permitted for address-only pointers since the provenance could be different.



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