[PATCH] D47399: Add _LIBCPP_LARGE_CODEBASE

[Tom Anderson via Phabricator via llvm-commits]

thomasanderson marked 2 inline comments as done.
thomasanderson added inline comments.


================
Comment at: include/__config:791
+#ifdef _LIBCPP_LARGE_CODEBASE
+#define _LIBCPP_TWEAK_INLINE_VISIBILITY __attribute__ ((noinline))
+#define _LIBCPP_TWEAK_ALWAYS_INLINE _LIBCPP_ALWAYS_INLINE
----------------
EricWF wrote:
> I don't have a strong objection to the intention of the patch, but I really dislike the name.
Changed.  I'm also open to suggestions, so if you'd like anything in particular, plmk.


================
Comment at: include/__config:793
+#define _LIBCPP_TWEAK_ALWAYS_INLINE _LIBCPP_ALWAYS_INLINE
+#define _LIBCPP_TWEAK_NEVER_INLINE __attribute__ ((noinline))
+#else
----------------
pcc wrote:
> 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.)
Removed new inline annotations from declarations.


https://reviews.llvm.org/D47399