<div dir="ltr">Yes, we are. Sorry about the delayed response.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 20, 2018 at 8:31 AM Louis Dionne <<a href="mailto:ldionne@apple.com">ldionne@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Nice! Just to confirm, if you are using the candidate Clang-7, you are building with `-D_LIBCPP_HIDE_FROM_ABI_PER_TU=1`, right?<div><br></div><div>Louis<br><div><br><blockquote type="cite"><div>On Aug 20, 2018, at 11:28, Erik van der Poel <<a href="mailto:erikv@google.com" target="_blank">erikv@google.com</a>> wrote:</div><br class="m_-210249269712362388Apple-interchange-newline"><div><div dir="ltr">Thank you for doing this, Louis! Our large stack frame problem has gone away.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 12, 2018 at 8:13 AM Louis Dionne via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Jul 10, 2018, at 19:42, Louis Dionne via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_-210249269712362388m_9132997496890286805Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><blockquote type="cite"><div><br class="m_-210249269712362388m_9132997496890286805Apple-interchange-newline">On Jul 10, 2018, at 17:25, Louis Dionne via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_-210249269712362388m_9132997496890286805Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><blockquote type="cite"><div><br class="m_-210249269712362388m_9132997496890286805Apple-interchange-newline">On Jul 10, 2018, at 16:46, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:</div><div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">On Tue, Jul 10, 2018 at 1:13 PM, Louis Dionne<span class="m_-210249269712362388m_9132997496890286805Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:ldionne@apple.com" target="_blank">ldionne@apple.com</a>></span><span class="m_-210249269712362388m_9132997496890286805Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><br><div><span class="m_-210249269712362388m_9132997496890286805gmail-"><blockquote type="cite"><div>On Jul 10, 2018, at 10:07, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:</div><br class="m_-210249269712362388m_9132997496890286805gmail-m_-1744977764213608698Apple-interchange-newline"><div><div dir="ltr">[…]</div></div></blockquote></span><span class="m_-210249269712362388m_9132997496890286805gmail-"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">This would look something like:<br><br> <span class="m_-210249269712362388m_9132997496890286805Apple-converted-space"> </span>#ifdef _LIBCPP_NO_INTERNAL_LINKAGE_FOR_ABI_UNSTABLE_SYMBOLS<br> <span class="m_-210249269712362388m_9132997496890286805Apple-converted-space"> </span># define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__("hidden")))<br> <span class="m_-210249269712362388m_9132997496890286805Apple-converted-space"> </span>#else<br> <span class="m_-210249269712362388m_9132997496890286805Apple-converted-space"> </span># define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__("hidden"),internal_linkage))<br> <span class="m_-210249269712362388m_9132997496890286805Apple-converted-space"> </span>#endif<br><br>In the future, we can decide which default behavior we want, but for now, I suggest we stick to what we have right now, which is support for both (1) and (2). It would be fine to change this in the future if we make that decision.<br><br></blockquote><div><br></div><div>When we don’t have internal linkage, I suspect we'll want to keep `__always_inline__` as to prevent static libraries from providing each other with incompatible function definitions (I think this could occur?).</div></div></div></div></blockquote><div><br></div></span></div>The idea here is that some people don’t care about interoperability of static libraries (or, equivalently, object files) built with different libc++ headers. And since they don’t care about this, they’d rather not pay the cost of inlining or internal linkage, which is code bloat.</div></div></blockquote><div><br></div><div>The `__always_inline__` is always needed, at least when mixing ABI stable and ABI hidden symbols in a explicitly instantiated template. Here's a reproducer that should fail to link on GCC and Clang:</div><div><a href="https://godbolt.org/g/LLZGjG" target="_blank">https://godbolt.org/g/LLZGjG</a></div></div></div></blockquote><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">I don’t believe this example is conforming. Per <a href="http://eel.is/c++draft/temp.explicit#12" target="_blank">http://eel.is/c++draft/temp.explicit#12</a>, `__init` should still be instantiated in `main.o`, because `__init` is marked inline. I must be wrong because otherwise both GCC and Clang are compiling this wrong.</div></div></blockquote><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div>I’ve kicked off a thread on llvm-dev here to try to clarify the situation:<span class="m_-210249269712362388m_9132997496890286805Apple-converted-space"> </span><a href="http://lists.llvm.org/pipermail/llvm-dev/2018-July/124549.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2018-July/124549.html</a></div><div><br></div><div>I want to avoid at all costs getting stuck like all the previous times this topic was brought up, so let me scale down the proposal to something that will still relieve much of the pain, while letting space for improvement in the future. The new proposal would be:</div><div><br></div><div>1. Everything that is ABI stable is marked with a visibility macro like today (no change here).</div><div>2. Everything that is marked with `_LIBCPP_INLINE_VISIBILITY` today is marked with a new `_LIBCPP_HIDE_FROM_ABI` macro instead. This macro is defined to `__attribute__((__visibility__("hidden"), internal_linkage))`, or to `__attribute__((__visibility__("hidden"), __always_inline__))` if the `internal_linkage` attribute is not supported (e.g. GCC). There is no way to turn off both `internal_linkage` and `__always_inline__`, not until the issue brought up above is resolved. This would look something like this:</div><div><br></div><div> #if __has_attribute(internal_linkage)</div><div> # define _LIBCPP_INTERNAL_LINKAGE __attribute__ ((internal_linkage))</div><div> #else</div><div> # define _LIBCPP_INTERNAL_LINKAGE __attribute__ ((__always_inline__))</div><div> #endif</div><div><br></div><div> #ifndef _LIBCPP_HIDE_FROM_ABI</div><div> # define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__(“hidden”))) _LIBCPP_INTERNAL_LINKAGE</div><div> #endif</div><div><br></div><div>In the future, as a pure improvement, we can add an alternative definition of `_LIBCPP_HIDE_FROM_ABI` which uses neither `internal_linkage` nor `__always_inline__`, for those that don't care about static archive interoperability but care about code size.</div><div><br></div><div>3. We still don't touch `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` for now.</div><div><br></div><div>Concretely, this will solve the problem of abusive inlining of the vast majority of functions whenever libc++ is compiled on Clang, which is already a big improvement. And then I can go back to the design board to solve the remaining issues, having at least made a some progress.</div><div><br></div><div>What do you think?</div></div></div></blockquote><br></div><div>I’ve put up a patch implementing this scaled down proposal for review: <a href="https://reviews.llvm.org/D49240" target="_blank">https://reviews.llvm.org/D49240</a>. Once/If we go forward with this, I’m committed to explore ways of solving the remaining problems, which are (please LMK if you see something else):</div><div><br></div><div>1. `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` still uses `__always_inline__` and we’d like to get rid of this.</div><div>2. We’d like the ability to only specify hidden visibility, but let ODR-equivalent functions be deduplicated across TUs. This makes it unsafe to mix TUs built with different versions of libc++, but has the potential of saving on code size.</div><div><br></div><div>Louis</div><div><br></div></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div>