[all-commits] [llvm/llvm-project] f77a29: [MergeICmps] Perform dereferenceability check with...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f77a290a2ffeda2a9974e87fa9120044de0ed93f
      https://github.com/llvm/llvm-project/commit/f77a290a2ffeda2a9974e87fa9120044de0ed93f
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2026-06-12 (Fri, 12 Jun 2026)

  Changed paths:
    M llvm/lib/Transforms/Scalar/MergeICmps.cpp
    M llvm/test/Transforms/MergeICmps/X86/no-gep-other-work.ll
    M llvm/test/Transforms/MergeICmps/X86/opaque-ptr.ll

  Log Message:
  -----------
  [MergeICmps] Perform dereferenceability check with context (#202884)

To support deref-at-point semantics, we need to check dereferenceability
with a context instruction. Currently, MergeICmps does the check for
each individual load instruction. In this PR, I'm replacing this with a
check for all the loads that are part of a chain after they have been
collected, so we do the context-sensitive check only once.

The choice of context instruction is a bit tricky: Normally, this would
just be the first block in the chain (the "entry block"), but it's also
possible for the block to "do extra work", in which case it will get
split. If this happens, we should be checking at the splitting point, as
the extra work might be freeing the pointer.

Another question to consider here is whether we need to be concerned
about frees at all: After all, the original code will be accessing at
least one byte of the two objects, so doesn't that imply that it wasn't
freed already? This is indeed the case, as long as allocations cannot
shrink. This is something we currently don't allow, but I think it's
something we want to allow, so I'm going with the conservative treatment
here.



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