[llvm] [ValueTracking] Allow getUnderlyingPointer to look through inttoptr/ptrtoint round trip casts (PR #146432)

[Drew Kersnar via llvm-commits]

================
@@ -1602,6 +1602,8 @@ AliasResult BasicAAResult::aliasCheck(const Value *V1, LocationSize V1Size,
   // Figure out what objects these things are pointing to if we can.
   const Value *O1 = getUnderlyingObject(V1, MaxLookupSearchDepth);
   const Value *O2 = getUnderlyingObject(V2, MaxLookupSearchDepth);
+  removeRoundTripCasts(O1);
+  removeRoundTripCasts(O2);
----------------
dakersnar wrote:

@nikic I'm wondering if a less general change could be considered correct. It sounds like the change in getUnderlyingObject would not be correct for every user, but for this specific user of getUnderlyingObject, could it be correct to strip away this pattern as this pseudocode would do?

The reason this would be useful would be because it could open up an easy NoAlias result.

Lets say we have the following instruction `A`, that we are comparing to instruction `B` in BasicAliasAnalysis. Each have a different underlying global value, but `A`'s pointer is wrapped in the round trip cast.

`%A= getelementptr i8, ptr inttoptr (i32 ptrtoint (ptr @globalmem to i32) to ptr), i64 0`
`%B = getelementptr i8, ptr @globalmem_2, i64 0`

On line 1619 of this file, isIdentifiedObject is called on each underlying object. If we do not traverse through the inttoptr/ptrtoint round trip we do not identify the underlying object as a global value, and thus are not able to prove NoAlias with that check.

Is it possible this traversal is correct in this specific case, or is it the same problem as the more general optimizations?

![image](https://github.com/user-attachments/assets/b3e00f05-d911-4256-98c4-ae0b041fac20)



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