__builtin_object_size(ptr, 1) does not pierce inlining

[kees]

__builtin_object_size(ptr, 0) tracks object origins, but it seems "mode 1" does not. This breaks future FORTIFY_SOURCE improvements.

#include <stdint.h>
#include <string.h>
#include <stdio.h>

#define show(expr) printf("%s: %zu\n", #expr, expr)

struct object {
        int a;
        char buf[7];
        int c;
};

static inline void func(const char *ptr)
{
    show(__builtin_object_size(ptr, 0));
    show(__builtin_object_size(ptr, 1));
}

int main(void)
{
    struct object instance;

    show(__builtin_object_size(instance.buf, 0));
    show(__builtin_object_size(instance.buf, 1));

    func(instance.buf);

    return 0;
}

GCC:

__builtin_object_size(instance.buf, 0): 12
__builtin_object_size(instance.buf, 1): 7
__builtin_object_size(ptr, 0): 12
__builtin_object_size(ptr, 1): 7

Clang:

__builtin_object_size(instance.buf, 0): 12
__builtin_object_size(instance.buf, 1): 7
__builtin_object_size(ptr, 0): 12
__builtin_object_size(ptr, 1): 12

https://godbolt.org/z/4fMszME9e

[kees]

Opened upstream: llvm/llvm-project#53516

[kees]

If I use a reduced test case:

struct object {
        int a;
        char buf[7];
        int c;
};

static inline size_t func_inline(const char *ptr)
{
        return __builtin_object_size(ptr, 1);
}

int main(void)
{
    struct object instance;

    if (__builtin_object_size(instance.buf, 1) ==
        func_inline(instance.buf))
                return 0;
    return 1;
}

From the unoptimized IR via clang test.c -O2 -Xclang -disable-llvm-passes -emit-llvm -S -o test.ir I see it has already immediately replaced the first bos with a literal 7, and left the inlined bos as-is:

...
  %7 = call i64 @func_inline(i8* noundef %6)
  %8 = icmp eq i64 7, %7
...
   ; Function Attrs: inlinehint nounwind uwtable
define internal i64 @func_inline(i8* noundef %0) #2 {
  %2 = alloca i8*, align 8
  store i8* %0, i8** %2, align 8, !tbaa !3
  %3 = load i8*, i8** %2, align 8, !tbaa !3
  %4 = call i64 @llvm.objectsize.i64.p0i8(i8* %3, i1 false, i1 true, i1 false)
  ret i64 %4
}

Examining the optimization passes with opt -O2 -print-after-all -S test.ir 2>&1, I see first the inline has the store/load removed:

; Function Attrs: inlinehint nounwind readnone uwtable willreturn
define internal fastcc i64 @func_inline(i8* noundef readnone %0) unnamed_addr #2 {
  %2 = tail call i64 @llvm.objectsize.i64.p0i8(i8* %0, i1 false, i1 true, i1 false)
  ret i64 %2
}

and then later the inlining is processed:

*** IR Dump After Function Integration/Inlining ***; Function Attrs: nounwind uwtable
define dso_local i32 @main() local_unnamed_addr #0 {
  %1 = alloca %struct.object, align 4
  %2 = bitcast %struct.object* %1 to i8*
  call void @llvm.lifetime.start.p0i8(i64 16, i8* nonnull %2) #3
  %3 = getelementptr inbounds %struct.object, %struct.object* %1, i64 0, i32 1, i64 0
  %4 = call i64 @llvm.objectsize.i64.p0i8(i8* %3, i1 false, i1 true, i1 false) #3
  %5 = icmp eq i64 %4, 7
  %.0 = select i1 %5, i32 0, i32 1
  call void @llvm.lifetime.end.p0i8(i64 16, i8* nonnull %2) #3
  ret i32 %.0
}

Then the entire main collapses to return 1 after this pass:

*** IR Dump After Combine redundant instructions ***
; Function Attrs: nounwind readnone uwtable willreturn
define dso_local i32 @main() local_unnamed_addr #0 {
  ret i32 1
}

[kees]

In clang/lib/CodeGen/CGBuiltin.cpp for CodeGenFunction::emitBuiltinObjectSize I find this and start to worry:

  // LLVM only supports 0 and 2, make sure that we pass along that as a boolean.
  Value *Min = Builder.getInt1((Type & 2) != 0);

Does this mean that the frontend is doing a bos pass before emitting IR, and that the frontend has a different implementation of bos that supports mode 1?

[kees]

I can see that objectsize lacks any scope arguments. And after finding commit 3e3bb95b6951c313dd5dd1c099184c309a3952e2 I have a sinking feeling we need to adjust the IR to include a "scope" parameter (i.e. to gain Type 1 and Type 3 support).

Using pass_object_size is not remotely sufficient, as things like inline memcpy wrappers may be called from inlined functions themselves. Marking all functions with pass_object_size would be amusing, but, I suspect, horribly slow.

[nickdesaulniers]

Closing. The upstream report was closed by Richard Smith. It looks like v6 of the series has found that __attribute__((pass_object_size)) can be used here.