[all-commits] [llvm/llvm-project] d69ee8: [CaptureTracking] Remove dereferenceable_or_null s...

[Nikita Popov via All-commits]

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

  Changed paths:
    M llvm/include/llvm/Analysis/CaptureTracking.h
    M llvm/lib/Analysis/CaptureTracking.cpp
    M llvm/lib/Transforms/IPO/AttributorAttributes.cpp
    M llvm/lib/Transforms/Scalar/MemCpyOptimizer.cpp
    M llvm/test/Transforms/Attributor/nocapture-1.ll
    M llvm/test/Transforms/Attributor/nocapture-2.ll
    M llvm/test/Transforms/FunctionAttrs/nocapture.ll

  Log Message:
  -----------
  [CaptureTracking] Remove dereferenceable_or_null special case (#135613)

Remove the special case where comparing a dereferenceable_or_null
pointer with null results in captures(none) instead of
captures(address_is_null).

This special case is not entirely correct. Let's say we have an
allocated object of size 2 at address 1 and have a pointer `%p` pointing
either to address 1 or 2. Then passing `gep p, -1` to a
`dereferenceable_or_null(1)` function is well-defined, and allows us to
distinguish between the two possible pointers, capturing information
about the address.

Now that we ignore address captures in alias analysis, I think we're
ready to drop this special case. Additionally, if there are regressions
in other places, the fact that this is inferred as address_is_null
should allow us to easily address them if necessary.



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