[all-commits] [llvm/llvm-project] 09b088: [LangRef] Specify icmp on pointers to only compare...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 09b08855698fbfedb5ad0726cb97a5dfc33ad46a
      https://github.com/llvm/llvm-project/commit/09b08855698fbfedb5ad0726cb97a5dfc33ad46a
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2025-12-04 (Thu, 04 Dec 2025)

  Changed paths:
    M llvm/docs/LangRef.rst
    M llvm/lib/Analysis/Loads.cpp
    M llvm/lib/Target/AMDGPU/AMDGPULowerBufferFatPointers.cpp
    M llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
    M llvm/test/CodeGen/AMDGPU/lower-buffer-fat-pointers-pointer-ops.ll
    M llvm/test/Transforms/GVN/assume-equal.ll
    M llvm/test/Transforms/InstCombine/ptrtoaddr.ll

  Log Message:
  -----------
  [LangRef] Specify icmp on pointers to only compare address (#163936)

This changes LangRef to specify that pointer icmp only compares the
address bits of the pointers. That is, `icmp pred %a, %b` is equivalent
to `icmp pred ptrtoaddr(%a), ptrtoaddr(%b)`.

Similarly, it specifies that the `nonnull` attribute requires that the
address bits are non-zero.

There are a couple of motivations for this:

* 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).
* This matches (as far as I understand) the behavior of existing CHERI
implementations.
* 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.

In terms of implementation, this PR adjusts:
 * The AMDGPULowerBufferFatPointers pass.
* An InstCombine fold that may replace pointers with different
non-address bits.
 * The fold that replaces pointers based on dominating pointer equality.

It does not adjust:
* ISel, because we don't have in-tree targets where we can show a
difference.
* Various icmp+ptrtoint transforms, because we'll have to change this
code for ptrtoaddr optimization support anyway, and these changes are
tightly related.

Related discussion starting from:
https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/60?u=nikic



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications