[PATCH] D47399: Add _LIBCPP_LARGE_CODEBASE

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added inline comments.


================
Comment at: include/__config:793
+#define _LIBCPP_TWEAK_ALWAYS_INLINE _LIBCPP_ALWAYS_INLINE
+#define _LIBCPP_TWEAK_NEVER_INLINE __attribute__ ((noinline))
+#else
----------------
thomasanderson wrote:
> EricWF wrote:
> > I understand wanting to disable the forced inlining of functions, but I don't understand why you would want to explicitly disable inlining.
> > It seems like if the function shouldn't be inlined for performance reasons, that should be controlled by an optimizer flag, and if the optimizer isn't producing ideal code, that seems like an optimizer bug.
> I'm building Chromium on Linux with lld (without LTO) with -O2.  With the __attribute__((noinline))'s from this patch, the binary size is 194M, 203296816B.  Without the noinline's, it's 197M, 206227536B.
> 
> If I use -Os instead, the measurements are 191M, 200064384B and 192M, 200578400B.  Better, but still not perfect.
> 
> +pcc do you know why lld is having trouble noinlining these functions?
Since you have LTO disabled, the choice of linker shouldn't make a difference with regards to inlining here. (Even with LTO you shouldn't see a difference with Chromium because Chromium links with `--lto-O0`.)

Note that we're not trying to avoid inlining for performance reasons but for code size reasons. Finding a good heuristic for the latter in the inliner is, unfortunately, an unsolved problem as of yet. (One of the reasons is that the heuristic would need be something of the form "if I inline this, will it unblock other size optimizations on the inlined code" and LLVM's optimizers just don't work that way, at least not yet.)


================
Comment at: include/string:798
     basic_string(size_type __n, _CharT __c, const _Allocator& __a);
+    _LIBCPP_TWEAK_NEVER_INLINE
     basic_string(const basic_string& __str, size_type __pos, size_type __n,
----------------
EricWF wrote:
> Most of these functions *can't* be inlined by the compiler unless the `inline` keyword is explicitly specified because these functions are externally instantiated.
> 
> I suspect not only that these functions not need `__attribute__((noinline))` but that would implicitly have that effect if `__attribute__((always_inline))` was omitted.
You might consider moving these attributes onto the definitions, which is where the `inline` keyword should appear (or not appear) anyway.


https://reviews.llvm.org/D47399