[cfe-dev] Making lambda function name consistent with GCC?

[Nathan Sidwell via cfe-dev]

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>> 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>> 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>
>      >> 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>)
> 
>     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, 
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>
>      >> 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>
>      > 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>
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 


-- 
Nathan Sidwell