[all-commits] [llvm/llvm-project] 32cd18: [GVN] Look through select/phi when determining und...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 32cd18975d2e1de5a783e9b1c3c21a234d5723b4
      https://github.com/llvm/llvm-project/commit/32cd18975d2e1de5a783e9b1c3c21a234d5723b4
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2024-07-22 (Mon, 22 Jul 2024)

  Changed paths:
    M llvm/include/llvm/Analysis/ValueTracking.h
    M llvm/lib/Analysis/Loads.cpp
    M llvm/lib/Analysis/ValueTracking.cpp
    M llvm/test/Transforms/GVN/condprop.ll

  Log Message:
  -----------
  [GVN] Look through select/phi when determining underlying object (#99509)

This addresses an optimization regression in Rust we have observed after
https://github.com/llvm/llvm-project/pull/82458. We now only perform
pointer replacement if they have the same underlying object. However,
getUnderlyingObject() by default only looks through linear chains, not
selects/phis. In particular, this means that we miss cases involving
involving pointer induction variables.

This patch fixes this by introducing a new helper
getUnderlyingObjectAggressive() which basically does what
getUnderlyingObjects() does, just specialized to the case where we must
arrive at a single underlying object in the end, and with a limit on the
number of inspected values.

Doing this more expensive underlying object check has no measurable
compile-time impact on CTMark.



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