[llvm] [llvm] Fix behavior of llvm.objectsize in presence of negative / large offset (PR #115504)

[via llvm-commits]

================
@@ -580,6 +585,11 @@ bool llvm::getObjectSize(const Value *Ptr, uint64_t &Size, const DataLayout &DL,
   if (!Data.bothKnown())
     return false;
 
+  // We could compute an over-approximation in that situation, may be if
+  // Opts.EvalMode == Max, but let's bee conservative and bail out.
+  if (Data.Offset.isNegative())
+    return false;
----------------
serge-sans-paille wrote:

I'd say that the relevant part is 

```
 If it is not possible to determine which objects ptr points to at compile time, __builtin_object_size should return (size_t) -1
```

In our case we don't know to which object it points to (it's somewhere before the original array) then -1 ?
Actually any returned value would be correct because the access is UB.

A motivating example is the following:

https://godbolt.org/z/Evqbj5v4f

```
define i64 @pain(i1 %0) {
  %p = alloca [2 x i8], align 1
  br i1 %0, label %if.then, label %if.else

if.then:
  %p.then = getelementptr  [2 x i8], ptr %p, i64 0, i64 1
  br label %if.end

if.else:
  %p.else = getelementptr  [2 x i8], ptr %p, i64 0, i64 -1
  br label %if.end

if.end:
  %p.end = phi ptr [%p.else, %if.else], [%p.then, %if.then]
  %objsize = call i64 @llvm.objectsize.i64.p0(ptr %p.end, i1 false, i1 true, i1 false)
  ret i64 %objsize
}
```

for which we currently return 3, and we used to return 1. If we do so it's because we consider `%p.else` points to an object of size 3. It is inconsistent with the fact that 

```
define i64 @pain(i1 %0) {
  %p = alloca [2 x i8], align 1
  %p.end = getelementptr  [2 x i8], ptr %p, i64 0, i64 -1
  %objsize = call i64 @llvm.objectsize.i64.p0(ptr %p.end, i1 false, i1 true, i1 false)
  ret i64 %objsize
}
```

returns 0 (and always have). If we want the first example to be consistent with the second, which I don't hate, I think we have to make sure the first example return 1.

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