Add inline to uflow and underflow

[hiraditya]

Summary

Called from xsgetn in a loop. Helps with performance.

[ldionne]

libcxx/include/streambuf

284 ↗

(On Diff #216687)

What is _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY? I don't think I've seen it before and I can't seem to find it in the __config header.

[mclow.lists]

The templates basic_streambuf<char> and basic_streambuf<wchar> are externally instantiated in the libc++.dylib.
Marking them as inline would remove them from the dylib, breaking any existing binaries that refer to them.

Is that what you intend?

[hiraditya]

I only intend to inline uflow and underflow.

[mclow.lists]

In D66614#1656799, @hiraditya wrote:

I only intend to inline uflow and underflow.

I should have written:
Marking uflow and underflow as inline would remove them from the dylib, breaking any existing binaries that refer to them.

[hiraditya]

Is there a way to have them inlined and still keep the definition in a dylib. I thought inline (with default visibility) will keep the definition in the translation unit.

[ldionne]

Normally, inline is used to control the linkage of a function, so that it is ODR-deduplicated across TUs. Correctness of the program is the only thing it should be used for, if we rely on what optimizer folks tell us (e.g. in conferences).

For that reason, my first reaction would be to consider this failed optimization an optimizer bug, not a library bug.

[ldionne]

In D66614#1657962, @ldionne wrote:

For that reason, my first reaction would be to consider this failed optimization an optimizer bug, not a library bug.

And that, regardless of whether we can make it work as far as symbols-exported-from-the-dylib are concerned.

[hiraditya]

In D66614#1657962, @ldionne wrote:

Normally, inline is used to control the linkage of a function, so that it is ODR-deduplicated across TUs. Correctness of the program is the only thing it should be used for, if we rely on what optimizer folks tell us (e.g. in conferences).

inline hint is used to determine inlining threshold, so it does have effect on llvm's inlining decision. e.g., https://github.com/llvm-mirror/llvm/blob/master/lib/Analysis/InlineCost.cpp#L917

For that reason, my first reaction would be to consider this failed optimization an optimizer bug, not a library bug.

[hiraditya]

after collecting numbers

include/streambuf

     virtual basic_streambuf* setbuf(char_type* __s, streamsize __n);
     virtual pos_type seekoff(off_type __off, ios_base::seekdir __way,
                              ios_base::openmode __which = ios_base::in | ios_base::out);
     virtual pos_type seekpos(pos_type __sp,
                              ios_base::openmode __which = ios_base::in | ios_base::out);
     virtual int sync();
 
     // 27.6.2.4.3 Get area:
     virtual streamsize showmanyc();
     virtual streamsize xsgetn(char_type* __s, streamsize __n);
+    inline
     virtual int_type underflow();
+    inline
     virtual int_type uflow();
 
     // 27.6.2.4.4 Putback:
     virtual int_type pbackfail(int_type __c = traits_type::eof());
 
     // 27.6.2.4.5 Put area:
     virtual streamsize xsputn(const char_type* __s, streamsize __n);
     virtual int_type overflow(int_type __c = traits_type::eof());
 
 private: