[PATCH] Use returns_nonnull in BumpPtrAllocator and MallocAllocator to avoid null-check in placement new

[Aaron Ballman]

On Wed, Aug 20, 2014 at 2:06 PM, Hans Wennborg <hans at chromium.org> wrote:
> Hi majnemer, chandlerc,
>
> In both Clang and LLVM, this is a common pattern:
>
>   Size = sizeof(DeclRefExpr) + SomeExtraStuff;
>   void *Mem = Context.Allocate(Size, llvm::alignOf<DeclRefExpr>());
>   return new (Mem) DeclRefExpr(...);
>
> The annoying thing is that because the default placement-new operator has a nothrow specification, the compiler will insert a null check of Mem before calling the DeclRefExpr constructor. This null check is redundant for us, because we expect the allocation functions to never return null.
>
> By annotating the allocator functions with returns_nonnull, we can optimize away these checks. Compiling clang with a recent version of Clang and measuring with:
>
>   $ perf stat -r20 bin/clang.patch -fsyntax-only -w /tmp/gcc.c && perf stat -r20 bin/clang.orig -fsyntax-only -w /tmp/gcc.c
>
> Shows a 2.4% speed-up (+- 0.8%).
>
> The pattern occurs in LLVM too. Measuring with -O3 (and now using bzip2.c instead because it's smaller):
>
>   $ perf stat -r20 bin/clang.patch -O3 -w /tmp/bzip2.c  &&  perf stat -r20 bin/clang.orig -O3 -w /tmp/bzip2.c
>
> Shows 4.4 % speed-up (+- 1%).
>
>
> If anyone knows of a similar attribute we can use for MSVC, or some other technique to get rid off the null check there, please let me know.

There's not a __declspec for it that affects code generation (that I'm
aware of, at least), but there is a SAL annotation which would help if
we ever cared to run with /analyze (not that I've heard that
suggestion floated before): _Ret_notnull_

~Aaron