Mismatch between `@llvm.objectsize` and `__builtin_object_size` semantics

[nunoplopes]

See how these compile to LLVM IR:

unsigned long long f(int *p) {
    return __builtin_object_size(p, 2);
}

unsigned long long g(int *p) {
    return __builtin_object_size(p, 1);
}

IR:

define i64 @f(ptr %p) {
entry:
  %p.addr = alloca ptr, align 8
  store ptr %p, ptr %p.addr, align 8
  %0 = load ptr, ptr %p.addr, align 8
  %1 = call i64 @llvm.objectsize.i64.p0(ptr %0, i1 true, i1 true, i1 false)
  ret i64 %1
}

define i64 @g(ptr %p) {
entry:
  %p.addr = alloca ptr, align 8
  store ptr %p, ptr %p.addr, align 8
  %0 = load ptr, ptr %p.addr, align 8
  %1 = call i64 @llvm.objectsize.i64.p0(ptr %0, i1 false, i1 true, i1 false)
  ret i64 %1
}

gcc's website (https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html) specifies an interesting semantics:

If there are multiple objects ptr can point to and all of them are known at compile time, the returned number is the maximum of remaining byte counts in those objects if type & 2 is 0 and minimum if nonzero.

The deal is that we don't distinguish between those at the IR level. Optimizations like LowerConstantIntrinsics are always giving the max.

Maybe it's sufficient to change our semantics to say that it returns a number greater or equal to the number of remaining bytes? I think that's sufficient for the purposes of checking if memcpy is within bounds.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Nuno Lopes (nunoplopes)

See how these compile to LLVM IR: ```c unsigned long long f(int *p) { return __builtin_object_size(p, 2); }

unsigned long long g(int *p) {
return __builtin_object_size(p, 1);
}

IR:
```llvm
define i64 @<!-- -->f(ptr %p) {
entry:
  %p.addr = alloca ptr, align 8
  store ptr %p, ptr %p.addr, align 8
  %0 = load ptr, ptr %p.addr, align 8
  %1 = call i64 @<!-- -->llvm.objectsize.i64.p0(ptr %0, i1 true, i1 true, i1 false)
  ret i64 %1
}

define i64 @<!-- -->g(ptr %p) {
entry:
  %p.addr = alloca ptr, align 8
  store ptr %p, ptr %p.addr, align 8
  %0 = load ptr, ptr %p.addr, align 8
  %1 = call i64 @<!-- -->llvm.objectsize.i64.p0(ptr %0, i1 false, i1 true, i1 false)
  ret i64 %1
}

gcc's website (https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html) specifies an interesting semantics:

> If there are multiple objects ptr can point to and all of them are known at compile time, the returned number is the maximum of remaining byte counts in those objects if type & 2 is 0 and minimum if nonzero.

The deal is that we don't distinguish between those at the IR level. Optimizations like LowerConstantIntrinsics are always giving the max.

Maybe it's sufficient to change our semantics to say that it returns a number greater or equal to the number of remaining bytes? I think that's sufficient for the purposes of checking if memcpy is within bounds.

[nikic]

I'm very confused by this issue. We do distinguish these at the IR level, with different values for the min argument. And LowerConstantIntrinsics does lower these differently, giving 0 and SIZE_MAX respectively (for this case where no information is known).

[nunoplopes]

Ok, maybe this example makes more sense:

unsigned long long f(int c) {
    int *p = malloc(2);
    int *q = malloc(4);
    int *r = c ? p : q;
    return __builtin_object_size(r, xx);
}

Depending on the value of xx, the gcc documentation says that this function may either return 4 or unknown (0 or -1). It cannot return 2 or 5, for example.
LangRef doesn't talk about the maximum of incoming pointers or anything similar. My reading is that it returns the exact value of the concrete pointer that reaches the function at run-time, meaning it can return 2 or 4 at run-time. But 2 is not a valid return per gcc's documentation.

LLVM only has a flag to specify the unknown value (0 or -1). But it doesn't have a flag to specify what happens when we have multiple objects with different sizes flowing to the intrinsic. Not even sure how to specify that in IR, though 😅

[nikic]

Depending on the value of xx, the gcc documentation says that this function may either return 4 or unknown (0 or -1). It cannot return 2 or 5, for example.

Which value of xx are you talking about here? For xx=2 the value 2 is a valid return value -- and indeed what gcc returns.

I think I get what you mean now. You're talking about this sentence in LangRef right?

The second argument determines whether llvm.objectsize returns 0 (if true) or -1 (if false) when the object size is unknown.

This is indeed incorrect. What the flag actually controls is whether it returns a minimum or a maximum object size. This implies 0 and -1 for the unknown case, but also controls what happens when there are multiple objects.

[nikic]

I've put up #156309 to clarify LangRef. Let me know if that's not what you had in mind.

[nunoplopes]

Ah I misread gcc docs. I didn't realize that min/max and return 0/-1 on unknown were correlated: https://gcc.godbolt.org/z/xT9hc55dr

I got confused here:

If there are multiple objects ptr can point to and all of them are known at compile time, the returned number is the maximum of remaining byte counts in those objects if type & 2 is 0 and minimum if nonzero.