<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 15, 2018, at 5:41 PM, Kristina Brooks via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Well that was in my original suggestion, but I don't know who is in charge of IA64 mangling, I<br class="">don't think Clang developers can push a change like this forward without some RFC to whatever<br class="">committee maintains the IA64 ABI or am I wrong? I suppose libc++ ABI could be considered separate<br class="">enough in which case we just need to come up with a compatible scheme for "short" manglings that<br class="">is also guaranteed not to clash with the standard IA64 ABI.<br class=""><br class="">Since you and Eric are mostly in charge of libcxxabi, could you propose a draft for a compatible<br class="">short mangling that would allow doing this as a breaking change (for unstable ABI versions, even<br class="">2+ since it's not stable yet unless Fuchsia has settled on it)? That way it's possible to add that<br class="">into the Clang mangler. I'm still not sure if this requires a blessing from whoever is in charge<br class="">of IA64 ABI, I think that would be a good idea to mention the draft to them at least.<br class=""></div></div></blockquote><div><br class=""></div><div>According to: <a href="https://itanium-cxx-abi.github.io/cxx-abi/" class="">https://itanium-cxx-abi.github.io/cxx-abi/</a></div><div><br class=""></div><div>The primary discussion forum for the ABI is the <a href="http://github.com/itanium-cxx-abi/cxx-abi/" class="">GitHub repository</a>. Please open a new issue for any new topic you want to discuss. Previously, the ABI was discussed on a mailing list, cxx-abi-dev, whose <a href="http://sourcerytools.com/pipermail/cxx-abi-dev/" class="">archives</a> are still accessible.</div><div><br class=""></div><div>CC’ing John since he’ll know more about this, seeing as how he’s the most active contributor to the repository :-)</div><div><br class=""></div><div>This issue from Richard seems like a good starting point: <a href="https://github.com/itanium-cxx-abi/cxx-abi/issues/42" class="">https://github.com/itanium-cxx-abi/cxx-abi/issues/42</a></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Thanks.<br class=""><br class="">On 16/11/2018 01:26, Louis Dionne wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class=""><blockquote type="cite" class="">On Nov 15, 2018, at 20:06, JF Bastien via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a>> wrote:<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Nov 15, 2018, at 3:59 PM, Kristina Brooks via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a>> wrote:<br class=""><br class="">Yes exactly, seems like an obvious win on a mono-ABI system, if preserving debug data<br class="">this saves a lot, not to mention symbol table strings. Also, I'm purely speculating here<br class="">but this would also speed up compilation and linking time by an insignificant margin, but<br class="">nevertheless, it's an improvement.<br class=""><br class="">If the ABI ever needs to change, on those kinds of systems, it's easy enough with an OS<br class="">update.<br class=""></blockquote><br class="">Or, we could update the Itanium ABI so that the current mangling still works and is compatible with a new mangling which is shorter for libc++ (yet remains purposefully incompatible with libstdc++’s mangling) 🙂<br class=""><br class=""></blockquote><br class="">Is it necessary/desirable to distinguish between implementations of the standard library at the Itanium ABI level? Wouldn't it be possible to define a compressed scheme for `std::__N` in full generality, and handle the ability to differentiate between implementations differently?<br class=""></blockquote></div></div></blockquote><div><br class=""></div><div>What I had in mind was distinguishing `std::__N` as you say, and by construction that would distinguish between implementations because libc++ and libstdc++ use different namespaces.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">Louis<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">Thanks.<br class=""><br class="">On 14/11/2018 17:06, Eric Fiselier wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class="">On Wed, Nov 14, 2018 at 12:04 PM Eric Fiselier <<a href="mailto:eric@efcs.ca" class="">eric@efcs.ca</a> <<a href="mailto:eric@efcs.ca" class="">mailto:eric@efcs.ca</a>>> wrote:<br class=""><br class=""> The itanium specification provides special compressed mangled names for std::string when it's not in an inline<br class=""> namespace [1]<br class=""><br class=""> Specifically, `Ss` vs `St3__112basic_string`<br class=""><br class=""><br class="">Correction... `Ss` vs `NSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE`<br class=""><br class=""><br class=""><br class=""> [1] <a href="https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-compression" class="">https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-compression</a><br class=""><br class=""> On Wed, Nov 14, 2018 at 10:03 AM Marshall Clow via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a><br class=""> <<a href="mailto:libcxx-dev@lists.llvm.org" class="">mailto:libcxx-dev@lists.llvm.org</a>>> wrote:<br class=""><br class=""> On Sun, Nov 11, 2018 at 9:49 PM Kristina Brooks via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a><br class=""> <<a href="mailto:libcxx-dev@lists.llvm.org" class="">mailto:libcxx-dev@lists.llvm.org</a>>> wrote:<br class=""><br class=""> Hi,<br class=""><br class=""> I was wondering, would it be possible to add an option to disable inline namespacing completely (as a CMake<br class=""> configuration flag) in libc++ for the sake of being able to use shorthand mangling and without having to<br class=""> resort to<br class=""> handling it on IA64 mangler level. This has many use cases for example distributions of anything that<br class=""> includes libc++ as<br class=""> one and only libc++ and does not allow non-vendor software to be installed. On an embedded system, assuming<br class=""> debug info<br class=""> is generated, and given how common some of the debug data takes a very significant amount of space given the<br class=""> complex<br class=""> definition of something like `std::__2::basic_string<...>` versus the short form (`std::string` having a<br class=""> shorthand<br class=""> mangling is a godsend since it's 95% shorter, not an accurate figure but basically definitely above 90%).<br class=""><br class=""><br class=""> I'm confused here.<br class=""> Why are you comparing `std::string` to `std::__2::basic_string<......" ?<br class=""><br class=""> `std::__2::string` is quite short.<<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a>><br class=""><br class=""> -- Marshall<br class=""><br class=""> _______________________________________________<br class=""> libcxx-dev mailing list<br class=""> <a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a> <<a href="mailto:libcxx-dev@lists.llvm.org" class="">mailto:libcxx-dev@lists.llvm.org</a>><br class=""> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br class=""><br class=""></blockquote>_______________________________________________<br class="">libcxx-dev mailing list<br class=""><a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev<br class=""></blockquote><br class="">_______________________________________________<br class="">libcxx-dev mailing list<br class=""><a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev<br class=""></blockquote><br class=""></blockquote>_______________________________________________<br class="">libcxx-dev mailing list<br class=""><a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev<br class=""></div></div></blockquote></div><br class=""></body></html>