[clang] [clang][CodeGen] Use ptrtoaddr for the pointer-overflow check (PR #223446)

[Adam Magier via cfe-commits]

================
@@ -6378,10 +6378,8 @@ static GEPOffsetAndOverflow EmitGEPOffsetInBytes(Value *BasePtr, Value *GEPVal,
   if (isa<llvm::Constant>(GEPVal)) {
     // Compute the offset by casting both pointers to integers and subtracting:
     // GEPVal = BasePtr + ptr(Offset) <--> Offset = int(GEPVal) - int(BasePtr)
-    Value *BasePtr_int =
-        Builder.CreatePtrToInt(BasePtr, DL.getIntPtrType(BasePtr->getType()));
-    Value *GEPVal_int =
-        Builder.CreatePtrToInt(GEPVal, DL.getIntPtrType(GEPVal->getType()));
+    Value *BasePtr_int = Builder.CreatePtrToAddr(BasePtr);
+    Value *GEPVal_int = Builder.CreatePtrToAddr(GEPVal);
----------------
AdamMagierFOSS wrote:

Refactoring seems reasonable here, but IMO it's a bit out of scope and I'm not 100% convinced it's NFC. Took a stab at the refactor locally and it's structurally simple enough - replacing the `*GEPVal` parameter with `*ElemTy` and `IdxList` allows the removal of this constant block and the subsequent asserts, and the iterators at 6430 just need to be initialized differently - but the main caveat is the refactor removes the hardcoded `OffsetOverflows = Builder.getFalse()` for constants. I suspect it'd be fine but I'd like to test that a bit more thoroughly, and I'd like to get this PR in to address some downstream behaviour.

If you're okay with it I'd prefer to push out the refactor in a different PR which I could do very shortly after this lands. Let me know if this is okay.

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