[cfe-dev] Making lambda function name consistent with GCC?
Nathan Sidwell via cfe-dev
cfe-dev at lists.llvm.org
Wed May 5 10:56:58 PDT 2021
On 5/5/21 1:37 PM, Richard Smith wrote:
> On Mon, 3 May 2021 at 10:36, Nathan Sidwell via cfe-dev
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
> On 5/3/21 12:42 PM, David Blaikie via cfe-dev wrote:
> >
> >
> > On Mon, May 3, 2021 at 4:10 AM Nathan Sidwell via cfe-dev
> > <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>> wrote:
> >
> > On 4/30/21 1:52 PM, Fāng-ruì Sòng via cfe-dev wrote:
> > > Redirect to cfe-dev.
> > >
> > > On Fri, Apr 30, 2021 at 9:42 AM Xun Li via llvm-dev
> > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>>
> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I noticed that when compiling lambda functions, the generated
> > function
> > >> names use different conventions than GCC.
> > >> Example: https://godbolt.org/z/5qvqKqEe6
> <https://godbolt.org/z/5qvqKqEe6>
> > <https://godbolt.org/z/5qvqKqEe6
> <https://godbolt.org/z/5qvqKqEe6>>
> > >> The lambda in Clang is named "_Z3barIZ3foovE3$_0EvT_",
> while the one
> > >> in GCC is named "_Z3barIZ3foovEUlvE_EvT_". Their
> demangled names are
> > >> also different ("void bar<foo()::$_0>(foo()::$_0)" vs "void
> > >> bar<foo()::{lambda()#1}>(foo()::{lambda()#1})").
> > >> Lambdas are not covered by the ABI so this is OK.
> >
> > Actually, they are. See 5.1.8 of the ABI doc
> > (https://github.com/itanium-cxx-abi/cxx-abi
> <https://github.com/itanium-cxx-abi/cxx-abi>
> > <https://github.com/itanium-cxx-abi/cxx-abi
> <https://github.com/itanium-cxx-abi/cxx-abi>>)
> >
> > The reason is that these symbols do escape into object files with
> > external linkage (not something originally anticipated).
> >
> >
> > Could you provide a quick example of this ABI break (where two files
> > compiled with matching compiler (GCC or Clang) link/run
> correctly, but
> > mismatching in either direction fails to link/run correctly)?
>
> hm, it turned out to be not quite the case I was thinking of:
>
> // header.h
> template<typename T> int bar (T) {static int i; return i++; }
>
> // the following lambda is attached to 'ctr', and therefore the
> // same type in every TU, you need gcc >= 10 to get this right.
> // not sure if clang models that correctly (given the template
> // mangling bug). And yes, this idiom exists in header files
> // -- I'm looking at you, ranges library :)
> auto ctr = [](){};
>
> // TUa.cc
> #include "header.h"
>
> // these instantiations are _Z3barIN3ctrMUlvE_EEiT_ due to the
> // above-mentioned attachment
> int maker1 () { return bar (ctr); }
>
> // TUb.cc
> #include "header.h"
> int maker2 () { return bar (ctr); }
>
> Those maker[12] functions are calling the exact same bar instantiation,
>
>
> I don't think that's right -- this program contains an ODR violation due
> to redefinition of 'ctr' (with two different types) in TUa and TUb.
Oh, I forgot to make 'ctr' inline -- that would remove that ODR, right?
(Or am I just confusing trauma from header-units :) )
> There is no ABI requirement to use a specific mangling for entities that
> are not externally visible, and Clang takes advantage of this to avoid
> strictly numbering lambdas that are only visible in a single TU. Though
> it's unfortunate that we put a '$' in the name in such cases; that seems
> to confuse some demanglers that incorrectly think that identifiers can
> contain only [A-Za-z0-9_], and results in a demangling that doesn't
> mention that we are inside a lambda.
>
> so should see consistent numbering from the static variable.
>
> hope that helps.
> >
> >
> > >> However there are use-cases where I find it very
> inconvenient when
> > >> they generate different names. For example, if we are to
> compare the
> > >> performance difference of the same software compiled
> under Clang and
> > >> GCC, the perf stack traces will look very different
> because of the
> > >> naming differences, making it hard to compare.
> > >> Is there any particular reason that Clang uses a
> different naming
> > >> convention for lambdas, and would there be push-backs if
> we were to
> > >> make it consistent with GCC?
> >
> > It would be good to have clang match the ABI. I am not sure
> how much
> > pain it would be for users to switch though -- perhaps having two
> > manglings and therefore two distinct instances in the same
> executable.
> > Other than code bloat most would not notice, unless someone put a
> > static
> > var into their lambda operator.
> >
> > >> Thanks.
> > >>
> > >> --
> > >> Xun
> > >> _______________________________________________
> > >> LLVM Developers mailing list
> > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> <mailto:llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> > <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>>
> > > _______________________________________________
> > > cfe-dev mailing list
> > > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> > <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>>
> > >
> >
> >
> > --
> > Nathan Sidwell
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> <mailto:cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> > <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>>
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> >
>
>
> --
> Nathan Sidwell
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
--
Nathan Sidwell
More information about the cfe-dev
mailing list