[llvm-dev] [cfe-dev] [RFC] attribute((internal_linkage))

Mon Nov 9 10:48:38 PST 2015

Sorry, I totally missed updates to this thread.

Anonymous namespace does not work for libc++ because we need to hide
some class members, and export the rest. Namespace would hide all of
them. AFAIK, "static" is un-deprecated in C++11 for multiple reasons,
including this one.

I agree that nodebug should not affect codegen. It would also kill
debug info (ex. all debug locations in libc++ headers).

On Mon, Nov 2, 2015 at 11:57 AM, Robinson, Paul via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris
>> Lattner via llvm-dev
>> Sent: Saturday, October 31, 2015 2:58 PM
>> To: sstewartgallus00 at mylangara.bc.ca
>> Cc: LLVM Developers
>> Subject: Re: [llvm-dev] [cfe-dev] [RFC] __attribute__((internal_linkage))
>>
>> Hi Stewart,
>>
>> I saw this get brought up at the LLVM devmtg in the context of improving
>> the stack size of libc++ frames.
>>
>> Have you guys considered a different approach to solving this problem?  In
>> the case of libc++, the _LIBCPP_INLINE_VISIBILITY macro currently expands
>> out to "__attribute__ ((__always_inline__))”.  It seems reasonable to me
>> to have it also add the “nodebug” attribute as well.  This should allow
>> the allocas generated by inlining lots of frames to be promoted to
>> registers (because there is no debug info to pessimize).
>
> Are you suggesting that 'nodebug' should affect code generation?
> It most definitely should not...
> --paulr
>
>>
>> This would dramatically shrink the stack frames of code using libc++ at -
>> O0, and would also make it go a lot faster.
>>
>> -Chris
>>
>>
>> > On Oct 29, 2015, at 6:35 AM, Martin J. O'Riordan via llvm-dev <llvm-
>> dev at lists.llvm.org> wrote:
>> >
>> > I haven't been able to figure out from this thread why this attribute is
>> necessary at all.
>> >
>> > Anonymous or unnamed namespaces were added to C++ for this very purpose,
>> but the ISO C++ Standard does not discuss "linkage" per-se because it is
>> outside the scope of the language specification.  But it does describes it
>> in terms of having a hidden name which is "unique" to the translation
>> unit, and under the "as if" rule, internal linkage is a common convention
>> for achieving this.
>> >
>> > This is just Standardese for dealing with what compiler implementers
>> typically handle as "internal linkage" anyway; at the same time, the use
>> of 'static' for this purpose was deprecated.  This is specifically stated
>> in C++98 section 7.3.1.1 and unnamed namespaces are still similarly
>> defined in C++17 (Working Paper) although the specific reference to the
>> deprecation of 'static' for this purpose is now gone.
>> >
>> > The closest the Standard gets to talking about linkage is with Linkage
>> Specifications, and even here it tries to avoid to avoid treading on the
>> definitions things like internal versus external linkage.
>> >
>> > So I am curious, what does this proposed attribute on namespaces achieve
>> that cannot already be achieved with an anonymous or unnamed namespace?
>> >
>> > Thanks,
>> >
>> >     Martin O'Riordan - Movidius Ltd.
>> >
>> > -----Original Message-----
>> > From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of
>> Evgenii Stepanov via cfe-dev
>> > Sent: 23 October 2015 22:41
>> > To: Steven Stewart-Gallus <sstewartgallus00 at mylangara.bc.ca>
>> > Cc: Clang Dev <cfe-dev at lists.llvm.org>
>> > Subject: Re: [cfe-dev] [RFC] __attribute__((internal_linkage))
>> >
>> > Sounds right. The proposed attribute is a rough equivalent of
>> >
>> > static void foo::do_method(void)
>> > {
>> >  // implementation here
>> > }
>> >
>> > where "static" does not mean a static class member, but makes the
>> declaration local to the translation unit. C-style "static".
>> >
>> > The patch in http://reviews.llvm.org/D13925 (waiting for review, btw!)
>> supports this attribute on classes and namespaces, with this syntax:
>> >
>> > namespace __attribute__((internal_linkage)) { }
>> >
>> >
>> > On Fri, Oct 23, 2015 at 9:03 AM, Steven Stewart-Gallus via cfe-dev <cfe-
>> dev at lists.llvm.org> wrote:
>> >> Hello,
>> >>
>> >> Can I ask for some clarification?
>> >>
>> >> Apparently, C++ doesn't allow to static class methods?
>> >>
>> >> While in C one might write inside a header file:
>> >>
>> >> static inline void mylib_foo_do_method(struct mylib_foo *foo) {
>> >>   // implementation here
>> >> }
>> >>
>> >> In C++ the typical style would be to write something like:
>> >>
>> >> namespace mylib {
>> >>
>> >> void foo::do_method(void)
>> >> {
>> >>  // implementation here
>> >> }
>> >> }
>> >>
>> >> Unfortunately, the C++ case then implies some linkage behaviour that
>> >> some might not want.
>> >>
>> >> Apparently, one can't do things like:
>> >>
>> >> namespace mylib {
>> >>
>> >> static void foo::do_method(void)
>> >> {
>> >>  // implementation here
>> >> }
>> >> }
>> >>
>> >> Or,
>> >>
>> >> namespace {
>> >> namespace mylib {
>> >>
>> >> static void foo::do_method(void)
>> >> {
>> >>  // implementation here
>> >> }
>> >> }
>> >> }
>> >>
>> >> Also, if you wanted to an attribute to a whole namespace you should do
>> >> something like the following I think:
>> >>
>> >> namespace mylib {
>> >> [[clang::internal_linkage]];
>> >>
>> >> static void foo::do_method(void)
>> >> {
>> >>  // implementation here
>> >> }
>> >> }
>> >>
>> >>
>> >> Thank you,
>> >> Steven Stewart-Gallus
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> cfe-dev at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev