How to easily identify that a FUNCTION_DECL is a lambda

How to easily identify that a FUNCTION_DECL is a lambda

[Martin Liška]

Hi.

For purpose of --coverage I would like to distinguish lambda functions
among DECL_ARTIFICIAL functions. Currently, cp-tree.h provides macro:

/* Test if FUNCTION_DECL is a lambda function.  */
#define LAMBDA_FUNCTION_P(FNDECL)				\
  (DECL_DECLARES_FUNCTION_P (FNDECL)				\
   && DECL_OVERLOADED_OPERATOR_P (FNDECL)			\
   && DECL_OVERLOADED_OPERATOR_IS (FNDECL, CALL_EXPR)		\
   && LAMBDA_TYPE_P (CP_DECL_CONTEXT (FNDECL)))

That's FE-specific function that probably should not be called from
middle-end. Any idea how to distinguish lambdas?

Thanks,
Martin

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Nathan Sidwell]

On 07/16/2018 03:23 AM, Martin Liška wrote:
> Hi.
> 
> For purpose of --coverage I would like to distinguish lambda functions
> among DECL_ARTIFICIAL functions. Currently, cp-tree.h provides macro:
> 
> /* Test if FUNCTION_DECL is a lambda function.  */
> #define LAMBDA_FUNCTION_P(FNDECL)				\
>    (DECL_DECLARES_FUNCTION_P (FNDECL)				\
>     && DECL_OVERLOADED_OPERATOR_P (FNDECL)			\
>     && DECL_OVERLOADED_OPERATOR_IS (FNDECL, CALL_EXPR)		\
>     && LAMBDA_TYPE_P (CP_DECL_CONTEXT (FNDECL)))
> 
> That's FE-specific function that probably should not be called from
> middle-end. Any idea how to distinguish lambdas?

You're going to need a language hook.  Lambda fns are just regular 
member fns outside the front-end.  Make the hook more than 
'lambda_fn_p', so it can extend to other exciting C++ features.  Perhaps 
something like:

enum synthetic_fn_kind {
   sfk_none,
   sfk_cxx_lambda,
};
synthetic_fn_kind (*categorize_artificial_fn) (tree decl);

We'll have to expose the union of FE's such sythetic fns to the middle 
end, but at least not how the FE distinguishes them.

Hm, but isn't this info lost if we're in LTO at this point?  Not sure if 
we'll need to propagate this through the LTO streaming.  I guess that's 
a later bug to handle though.

nathan

-- 
Nathan Sidwell

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Richard Biener]

On July 16, 2018 4:30:42 PM GMT+02:00, Nathan Sidwell <nathan@acm.org> wrote:
>On 07/16/2018 03:23 AM, Martin Liška wrote:
>> Hi.
>> 
>> For purpose of --coverage I would like to distinguish lambda
>functions
>> among DECL_ARTIFICIAL functions. Currently, cp-tree.h provides macro:
>> 
>> /* Test if FUNCTION_DECL is a lambda function.  */
>> #define LAMBDA_FUNCTION_P(FNDECL)				\
>>    (DECL_DECLARES_FUNCTION_P (FNDECL)				\
>>     && DECL_OVERLOADED_OPERATOR_P (FNDECL)			\
>>     && DECL_OVERLOADED_OPERATOR_IS (FNDECL, CALL_EXPR)		\
>>     && LAMBDA_TYPE_P (CP_DECL_CONTEXT (FNDECL)))
>> 
>> That's FE-specific function that probably should not be called from
>> middle-end. Any idea how to distinguish lambdas?
>
>You're going to need a language hook.  Lambda fns are just regular 
>member fns outside the front-end.  Make the hook more than 
>'lambda_fn_p', so it can extend to other exciting C++ features. 
>Perhaps 
>something like:
>
>enum synthetic_fn_kind {
>   sfk_none,
>   sfk_cxx_lambda,
>};
>synthetic_fn_kind (*categorize_artificial_fn) (tree decl);
>
>We'll have to expose the union of FE's such sythetic fns to the middle 
>end, but at least not how the FE distinguishes them.
>
>Hm, but isn't this info lost if we're in LTO at this point?  Not sure
>if 
>we'll need to propagate this through the LTO streaming.  I guess that's
>
>a later bug to handle though.

Just use a spare bit in function_decl, then we can simply stream it. 

Richard. 

>nathan

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Nathan Sidwell]

On 07/16/2018 12:04 PM, Richard Biener wrote:

> Just use a spare bit in function_decl, then we can simply stream it.

If there's one, then sure.  (you've reminded me that there are a bunch 
of mutually disjoint flags in function_decl that could be collapsed to 
an enumeration.  This may be another such bit.)

nathan

-- 
Nathan Sidwell

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

On 07/16/2018 06:09 PM, Nathan Sidwell wrote:
> On 07/16/2018 12:04 PM, Richard Biener wrote:
> 
>> Just use a spare bit in function_decl, then we can simply stream it.
> 
> If there's one, then sure.  (you've reminded me that there are a bunch of mutually disjoint flags in function_decl that could be collapsed to an enumeration.  This may be another such bit.)

There wasn't, but I was able to stole one unused (tm_clone_flag). About mutual disjoint, I believe following 3 can be
an enum:

  unsigned static_ctor_flag : 1;
  unsigned static_dtor_flag : 1;
  unsigned lambda_function: 1;

I'm attaching patch candidate, is the location where I set the flag correct?
Do I miss any other location where that should be set?

Thanks,
Martin

> 
> nathan
> 


[-- Attachment #2: lambda.patch --]
[-- Type: text/x-patch, Size: 2151 bytes --]

diff --git a/gcc/coverage.c b/gcc/coverage.c
index da171c84d3c..a0506b74f82 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -656,7 +656,8 @@ coverage_begin_function (unsigned lineno_checksum, unsigned cfg_checksum)
   gcov_write_unsigned (cfg_checksum);
   gcov_write_string (IDENTIFIER_POINTER
 		     (DECL_ASSEMBLER_NAME (current_function_decl)));
-  gcov_write_unsigned (DECL_ARTIFICIAL (current_function_decl));
+  gcov_write_unsigned (DECL_ARTIFICIAL (current_function_decl)
+		       && !DECL_CXX_LAMBDA_FUNCTION (current_function_decl));
   gcov_write_filename (xloc.file);
   gcov_write_unsigned (xloc.line);
   gcov_write_unsigned (xloc.column);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d0f1e1e9701..bc65fa98b14 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -10639,6 +10639,7 @@ cp_parser_lambda_declarator_opt (cp_parser* parser, tree lambda_expr)
 	DECL_ARTIFICIAL (fco) = 1;
 	/* Give the object parameter a different name.  */
 	DECL_NAME (DECL_ARGUMENTS (fco)) = get_identifier ("__closure");
+	DECL_CXX_LAMBDA_FUNCTION (fco) = 1;
       }
     if (template_param_list)
       {
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index 4a04e9e8b26..4771312f5b6 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1788,8 +1788,8 @@ struct GTY(()) tree_function_decl {
   unsigned pure_flag : 1;
   unsigned looping_const_or_pure_flag : 1;
   unsigned has_debug_args_flag : 1;
-  unsigned tm_clone_flag : 1;
   unsigned versioned_function : 1;
+  unsigned lambda_function: 1;
   /* No bits left.  */
 };
 
diff --git a/gcc/tree.h b/gcc/tree.h
index 79b675025d9..cb7975f9ba3 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -3043,6 +3043,10 @@ extern vec<tree, va_gc> **decl_debug_args_insert (tree);
 #define DECL_CXX_DESTRUCTOR_P(NODE)\
    (FUNCTION_DECL_CHECK (NODE)->decl_with_vis.cxx_destructor)
 
+/* In FUNCTION_DECL, this is set if this function is a C++ lambda function.  */
+#define DECL_CXX_LAMBDA_FUNCTION(NODE) \
+  (FUNCTION_DECL_CHECK (NODE)->function_decl.lambda_function)
+
 /* In FUNCTION_DECL that represent an virtual method this is set when
    the method is final.  */
 #define DECL_FINAL_P(NODE)\

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Richard Biener]

On Tue, Jul 17, 2018 at 1:35 PM Martin Liška <mliska@suse.cz> wrote:
>
> On 07/16/2018 06:09 PM, Nathan Sidwell wrote:
> > On 07/16/2018 12:04 PM, Richard Biener wrote:
> >
> >> Just use a spare bit in function_decl, then we can simply stream it.
> >
> > If there's one, then sure.  (you've reminded me that there are a bunch of mutually disjoint flags in function_decl that could be collapsed to an enumeration.  This may be another such bit.)
>
> There wasn't, but I was able to stole one unused (tm_clone_flag). About mutual disjoint, I believe following 3 can be
> an enum:

Well, /* No bits left.  */ is a lie on 64bit hosts.  There's actually
32bits left on those ;)
Similar in tree_decl_with_vis which _does_ have 14 unused bits left.
So we could
shrink FUNCTION_DECLs by 8 bytes by moving the function-decl flags to
decl_with_vis inside sth like

  union {
     struct { .... } function_decl_bits;
  } u;

if we ever choose to have other decl_with_vis nodes have flags.  But yes, the
function_decl_bits part would then be all taken.  OTOH decl_with_vis already
has a lot of FUNCTION_DECL-only flags already.

Care to move the bits?

>   unsigned static_ctor_flag : 1;
>   unsigned static_dtor_flag : 1;
>   unsigned lambda_function: 1;
>
> I'm attaching patch candidate, is the location where I set the flag correct?
> Do I miss any other location where that should be set?

> Thanks,
> Martin
>
> >
> > nathan
> >
>

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Jason Merrill]

On Mon, Jul 16, 2018 at 5:23 PM, Martin Liška <mliska@suse.cz> wrote:
> For purpose of --coverage I would like to distinguish lambda functions
> among DECL_ARTIFICIAL functions.

I'm curious, why?

Jason

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Martin Liška]

On 07/18/2018 03:45 AM, Jason Merrill wrote:
> On Mon, Jul 16, 2018 at 5:23 PM, Martin Liška <mliska@suse.cz> wrote:
>> For purpose of --coverage I would like to distinguish lambda functions
>> among DECL_ARTIFICIAL functions.
> 
> I'm curious, why?
> 
> Jason
> 

It's important for GCOV to report coverage for functions that are
really present in a source file. Lambdas are such functions.
On the other hand functions like _Z41__static_initialization_and_destruction_*
or some implicit constructors (Centering<3>::Centering(Centering<3> const&))
should not be reported. It confuses a user. Note that both have a valid
location and one can't distinguish them.

That's why I would like to sort out lambdas from others.

Martin

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Jason Merrill]

On Wed, Jul 18, 2018 at 7:03 PM, Martin Liška <mliska@suse.cz> wrote:
> On 07/18/2018 03:45 AM, Jason Merrill wrote:
>> On Mon, Jul 16, 2018 at 5:23 PM, Martin Liška <mliska@suse.cz> wrote:
>>> For purpose of --coverage I would like to distinguish lambda functions
>>> among DECL_ARTIFICIAL functions.
>>
>> I'm curious, why?
>
> It's important for GCOV to report coverage for functions that are
> really present in a source file. Lambdas are such functions.
> On the other hand functions like _Z41__static_initialization_and_destruction_*
> or some implicit constructors (Centering<3>::Centering(Centering<3> const&))
> should not be reported. It confuses a user. Note that both have a valid
> location and one can't distinguish them.

Those other functions may have *a* location, but only
DECL_SOURCE_LOCATION; could we distinguish on that basis?

Jason

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Martin Liška]

On 07/18/2018 02:40 PM, Jason Merrill wrote:
> On Wed, Jul 18, 2018 at 7:03 PM, Martin Liška <mliska@suse.cz> wrote:
>> On 07/18/2018 03:45 AM, Jason Merrill wrote:
>>> On Mon, Jul 16, 2018 at 5:23 PM, Martin Liška <mliska@suse.cz> wrote:
>>>> For purpose of --coverage I would like to distinguish lambda functions
>>>> among DECL_ARTIFICIAL functions.
>>>
>>> I'm curious, why?
>>
>> It's important for GCOV to report coverage for functions that are
>> really present in a source file. Lambdas are such functions.
>> On the other hand functions like _Z41__static_initialization_and_destruction_*
>> or some implicit constructors (Centering<3>::Centering(Centering<3> const&))
>> should not be reported. It confuses a user. Note that both have a valid
>> location and one can't distinguish them.
> 
> Those other functions may have *a* location, but only
> DECL_SOURCE_LOCATION; could we distinguish on that basis?
> 
> Jason
> 

I don't know how to distinguish them. Consider:

 <function_decl 0x7fffe82f7200 __dt_base 
    type <method_type 0x7fffe82f9000
        type <void_type 0x7ffff67c0f18 void type_6 VOID
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff67c0f18
            pointer_to_this <pointer_type 0x7ffff67c8000> reference_to_this <reference_type 0x7fffefb642a0>>
        QI
        size <integer_cst 0x7ffff67a2f60 constant 8>
        unit-size <integer_cst 0x7ffff67a2f78 constant 1>
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe82f62a0 method basetype <record_type 0x7fffe829abd0 BinaryNode>
        arg-types <tree_list 0x7fffeba3ffa0 value <pointer_type 0x7fffe82af000>
            chain <tree_list 0x7ffff67b6898 value <void_type 0x7ffff67c0f18 void>>>
        throws <tree_list 0x7ffff68f4050
            purpose <integer_cst 0x7ffff67c31f8 constant 1>>
        pointer_to_this <pointer_type 0x7fffe8344000>>
    nothrow public static weak autoinline decl_3 decl_5 QI tramp3d-v4.cpp:867:7 align:16 warn_if_not_align:0 context <record_type 0x7fffe829abd0 BinaryNode> initial <block 0x7fffe832eea0> abstract_origin <function_decl 0x7fffe82f7000 __dt >
    result <result_decl 0x7fffe8330f78 D.471838 type <void_type 0x7ffff67c0f18 void>
        ignored VOID tramp3d-v4.cpp:867:7
        align:8 warn_if_not_align:0 context <function_decl 0x7fffe82f7200 __dt_base >>
    full-name "BinaryNode<OpLT, Field<UniformRectilinearMesh<MeshTraits<3, double, UniformRectilinearTag, CartesianTag, 3> >, double, BrickView>, Scalar<double> >::~BinaryNode() noexcept"
    pending-inline-info 0x7fffe8341510
    arguments <parm_decl 0x7fffe82f5b00 this
        type <pointer_type 0x7fffe82af150 type <record_type 0x7fffe829abd0 BinaryNode>
            readonly unsigned DI
            size <integer_cst 0x7ffff67a2e70 constant 64>
            unit-size <integer_cst 0x7ffff67a2e88 constant 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe82af150>
        readonly unsigned read DI tramp3d-v4.cpp:34712:13 size <integer_cst 0x7ffff67a2e70 64> unit-size <integer_cst 0x7ffff67a2e88 8>
        align:64 warn_if_not_align:0 context <function_decl 0x7fffe82f7200 __dt_base > abstract_origin <parm_decl 0x7fffe82f5900 this> arg-type <pointer_type 0x7fffe82af150>>
    struct-function 0x7fffe833e580 chain <function_decl 0x7fffe82f7100 __dt_comp >>

it's DECL_SOURCE_LOCATION is:
$2 = 200862249

and expand_location (DECL_SOURCE_LOCATION (current_function_decl)) is:
(gdb) p xloc
$1 = {
  file = 0x2a58df0 "tramp3d-v4.cpp", 
  line = 867, 
  column = 7, 
  data = 0x0, 
  sysp = false
}

Martin

Re: How to easily identify that a FUNCTION_DECL is a lambda

[Martin Liška]

PING^1

On 07/18/2018 03:49 PM, Martin Liška wrote:
> On 07/18/2018 02:40 PM, Jason Merrill wrote:
>> On Wed, Jul 18, 2018 at 7:03 PM, Martin Liška <mliska@suse.cz> wrote:
>>> On 07/18/2018 03:45 AM, Jason Merrill wrote:
>>>> On Mon, Jul 16, 2018 at 5:23 PM, Martin Liška <mliska@suse.cz> wrote:
>>>>> For purpose of --coverage I would like to distinguish lambda functions
>>>>> among DECL_ARTIFICIAL functions.
>>>>
>>>> I'm curious, why?
>>>
>>> It's important for GCOV to report coverage for functions that are
>>> really present in a source file. Lambdas are such functions.
>>> On the other hand functions like _Z41__static_initialization_and_destruction_*
>>> or some implicit constructors (Centering<3>::Centering(Centering<3> const&))
>>> should not be reported. It confuses a user. Note that both have a valid
>>> location and one can't distinguish them.
>>
>> Those other functions may have *a* location, but only
>> DECL_SOURCE_LOCATION; could we distinguish on that basis?
>>
>> Jason
>>
> 
> I don't know how to distinguish them. Consider:
> 
>  <function_decl 0x7fffe82f7200 __dt_base 
>     type <method_type 0x7fffe82f9000
>         type <void_type 0x7ffff67c0f18 void type_6 VOID
>             align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff67c0f18
>             pointer_to_this <pointer_type 0x7ffff67c8000> reference_to_this <reference_type 0x7fffefb642a0>>
>         QI
>         size <integer_cst 0x7ffff67a2f60 constant 8>
>         unit-size <integer_cst 0x7ffff67a2f78 constant 1>
>         align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe82f62a0 method basetype <record_type 0x7fffe829abd0 BinaryNode>
>         arg-types <tree_list 0x7fffeba3ffa0 value <pointer_type 0x7fffe82af000>
>             chain <tree_list 0x7ffff67b6898 value <void_type 0x7ffff67c0f18 void>>>
>         throws <tree_list 0x7ffff68f4050
>             purpose <integer_cst 0x7ffff67c31f8 constant 1>>
>         pointer_to_this <pointer_type 0x7fffe8344000>>
>     nothrow public static weak autoinline decl_3 decl_5 QI tramp3d-v4.cpp:867:7 align:16 warn_if_not_align:0 context <record_type 0x7fffe829abd0 BinaryNode> initial <block 0x7fffe832eea0> abstract_origin <function_decl 0x7fffe82f7000 __dt >
>     result <result_decl 0x7fffe8330f78 D.471838 type <void_type 0x7ffff67c0f18 void>
>         ignored VOID tramp3d-v4.cpp:867:7
>         align:8 warn_if_not_align:0 context <function_decl 0x7fffe82f7200 __dt_base >>
>     full-name "BinaryNode<OpLT, Field<UniformRectilinearMesh<MeshTraits<3, double, UniformRectilinearTag, CartesianTag, 3> >, double, BrickView>, Scalar<double> >::~BinaryNode() noexcept"
>     pending-inline-info 0x7fffe8341510
>     arguments <parm_decl 0x7fffe82f5b00 this
>         type <pointer_type 0x7fffe82af150 type <record_type 0x7fffe829abd0 BinaryNode>
>             readonly unsigned DI
>             size <integer_cst 0x7ffff67a2e70 constant 64>
>             unit-size <integer_cst 0x7ffff67a2e88 constant 8>
>             align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe82af150>
>         readonly unsigned read DI tramp3d-v4.cpp:34712:13 size <integer_cst 0x7ffff67a2e70 64> unit-size <integer_cst 0x7ffff67a2e88 8>
>         align:64 warn_if_not_align:0 context <function_decl 0x7fffe82f7200 __dt_base > abstract_origin <parm_decl 0x7fffe82f5900 this> arg-type <pointer_type 0x7fffe82af150>>
>     struct-function 0x7fffe833e580 chain <function_decl 0x7fffe82f7100 __dt_comp >>
> 
> it's DECL_SOURCE_LOCATION is:
> $2 = 200862249
> 
> and expand_location (DECL_SOURCE_LOCATION (current_function_decl)) is:
> (gdb) p xloc
> $1 = {
>   file = 0x2a58df0 "tramp3d-v4.cpp", 
>   line = 867, 
>   column = 7, 
>   data = 0x0, 
>   sysp = false
> }
> 
> Martin
>