[libc++] Deducing this in string_view with LIBCXX_ABI_UNSTABLE

[libbooze]

One of motivating factors for Deducing this was performance

Would it be reasonable to implement string_view variant that uses Deducing this when users specify LIBCXX_ABI_UNSTABLE?
I understand this might require some benchmarks(both runtime and binary size on large projects) before we conclude it is best to do switch, but I think it might be interesting thing to do since string_view is heavily used.

[philnik777]

Why would you need to do it in the unstable ABI? More importantly, deducing this isn't available before C++23 in Clang currently, so we'd have to guard it behind macros, which would make the implementation most likely so much more complicated that it's not worth the tiny perf improvement for debug code.

[libbooze]

Why would you need to do it in the unstable ABI?

Since argument passing is part of ABI, I think

More importantly, deducing this isn't available before C++23 in Clang currently, so we'd have to guard it behind macros, which would make the implementation most likely so much more complicated that it's not worth the tiny perf improvement for debug code.

I think release code would benefit from this optimization. Not every function is inlined.

[philnik777]

Why would you need to do it in the unstable ABI?

Since argument passing is part of ABI, I think

It's only part of the function ABI, which we can change without problems for the most part.

More importantly, deducing this isn't available before C++23 in Clang currently, so we'd have to guard it behind macros, which would make the implementation most likely so much more complicated that it's not worth the tiny perf improvement for debug code.

I think release code would benefit from this optimization. Not every function is inlined.

Which one isn't in string_view?

[libbooze]

Why would you need to do it in the unstable ABI?

Since argument passing is part of ABI, I think

It's only part of the function ABI, which we can change without problems for the most part.

My mistake. Old string_view will call different begin, deducing this will call different begin because they are different functions.

What about people having pointers to string_view member functions? I presume we would break them?
https://godbolt.org/z/n6aMMb6sY

So this makes me question if standard would ever allow this implementation of string_view(even though callsites look same). But afaik users are not allowed to take addresses of standard functions so in theory we may be able to do this...
https://www.reddit.com/r/cpp_questions/comments/hewx2o/why_cant_i_take_an_address_of_a_standard_library/

More importantly, deducing this isn't available before C++23 in Clang currently, so we'd have to guard it behind macros, which would make the implementation most likely so much more complicated that it's not worth the tiny perf improvement for debug code.

I think release code would benefit from this optimization. Not every function is inlined.

Which one isn't in string_view?

Well I do not have that data, if you claim that with O2/O3 clang will inline every call to std::string_view member functions since you are familiar with generated asm I believe you.

If you know of a good project and how to check this please let me know. I tried to objdump/nm my chrome install, but binary seems to be build in a way this does not work, even for heavy functions like string::resize or std::stable_sort.

So what I would like to do:
find some large binary build in release, e.g. chrome, firefox, check if all of large % of calls to string_view member functions are inlined. If so this change would probably not bring any measurable benefits.

[frederick-vs-ja]

Could you post an example where a variant of string_view with explicit object member functions causes better codegen?

What about people having pointers to string_view member functions? I presume we would break them?

Such a usage is effectively disallowed by [member.functions]/2 (added by LWG2259), and/or P0551R3.

[philnik777]

Well I do not have that data, if you claim that with O2/O3 clang will inline every call to std::string_view member functions since you are familiar with generated asm I believe you.

I haven't looked at everything, but almost all functions in string_view are quite simple. The few that aren't call other functions, which would be used instead in the final binary.

If you know of a good project and how to check this please let me know. I tried to objdump/nm my chrome install, but binary seems to be build in a way this does not work, even for heavy functions like string::resize or std::stable_sort.

chrome and firefox are almost certainly stripped, so they wouldn't have any libc++ symbols. You'd most likely have to build them to get any information out of them.

[libbooze]

chrome and firefox are almost certainly stripped, so they wouldn't have any libc++ symbols. You'd most likely have to build them to get any information out of them.

Thank you. I assumed this, but hoped maybe you have some CI build where you build chrome or something with nightly of chrome+libc++ where I could get the release binary with symbols without building it myself. I guess time to build chrome on my machine.

[ldionne]

I am going to tentatively close this, please feel free to reopen once/if you have additional insights that mandate reconsidering this. Just trying to tidy up the issues list.