diff mbox

[committed] Dump function attributes

Message ID 560BB354.5040404@mentor.com
State New
Headers show

Commit Message

Tom de Vries Sept. 30, 2015, 10:03 a.m. UTC
On 29/09/15 13:29, Richard Biener wrote:
> On Tue, Sep 29, 2015 at 1:23 PM, Tom de Vries <Tom_deVries@mentor.com> wrote:
>> On 29/09/15 12:36, Richard Biener wrote:
>>>
>>> On Tue, Sep 29, 2015 at 7:43 AM, Tom de Vries <Tom_deVries@mentor.com>
>>> wrote:
>>>>
>>>> [ was: Re: [RFC] Dump function attributes ]
>>>>
>>>> On 28/09/15 17:17, Bernd Schmidt wrote:
>>>>>
>>>>>
>>>>> On 09/28/2015 04:32 PM, Tom de Vries wrote:
>>>>>>
>>>>>>
>>>>>> patch below prints the function attributes in the dump file.
>>>>>
>>>>>
>>>>>
>>>>>> foo ()
>>>>>> [ noclone , noinline ]
>>>>>> {
>>>>>> ...
>>>>>>
>>>>>> Good idea?
>>>>>>
>>>>>> If so, do we want one attribute per line?
>>>>>
>>>>>
>>>>>
>>>>> Only for really long ones I'd think. Patch is ok for now.
>>>>>
>>>>>
>>>>
>>>> Reposting patch with ChangeLog entry added.
>>>>
>>>> Bootstrapped and reg-tested on x86_64.
>>>>
>>>> Committed to trunk.
>>>
>>>
>>> Hmpf.  I always like to make the dump-files as much copy&past-able to
>>> testcases
>>> as possible.
>>
>>
>> Hmm, interesting. Not something I use, but I can imagine it's useful.
>>
>>> So why did you invent a new syntax for attributes instead of using
>>> the existing __attribute__(("noclone", "noinline")) (in this case)?
>>
>>
>> My main concerns were:
>> - being able to see in dump files what the actual attributes of a
>>    function are (rather than having to figure it out in a debug session).
>> - being able to write testcases that can test for the presence of those
>>    attributes in dump files
>>
>>> Did you verify
>>> how attributes with arguments get printed?
>>
>>
>> F.i. an oacc offload function compiled by the host compiler is annotated as
>> follows:
>>
>> before pass_oacc_transform (in the gomp-4_0-branch):
>> ...
>> [ oacc function 32, , , omp target entrypoint ]
>> ...
>>
>> after pass_oacc_transform:
>> ....
>> [ oacc function 1, 1, 1, omp target entrypoint ]
>> .
>
> Hmm, ok.  So without some extra dump_attribute_list wrapping
> __attribute_(( ... )) around the above doesn't make it more amenable
> for cut&pasting.
>

With attached untested follow-up patch, for test-case:
...
void __attribute__((noinline)) __attribute__((alias ("bar"), noclone))
foo (void)
{

}

void __attribute__ ((__target__ ("arch=core2", "sse3")))
foo2 (void)
{

}

void __attribute__ ((optimize ((1))))
foo3 (void)
{

}

void __attribute__ ((optimize (("1"))))
foo4 (void)
{

}
...

I get at gimple dump:
...
__attribute__((noclone, alias ("bar"), noinline))
foo ()
{

}


__attribute__((__target__ ("arch=core2", "sse3")))
foo2 ()
{

}


__attribute__((optimize (1)))
foo3 ()
{

}


__attribute__((optimize ("1")))
foo4 ()
{

}
...

OK if bootstrap/regtest succeeds?

Thanks,
- Tom

Comments

Richard Biener Sept. 30, 2015, noon UTC | #1
On Wed, Sep 30, 2015 at 12:03 PM, Tom de Vries <Tom_deVries@mentor.com> wrote:
> On 29/09/15 13:29, Richard Biener wrote:
>>
>> On Tue, Sep 29, 2015 at 1:23 PM, Tom de Vries <Tom_deVries@mentor.com>
>> wrote:
>>>
>>> On 29/09/15 12:36, Richard Biener wrote:
>>>>
>>>>
>>>> On Tue, Sep 29, 2015 at 7:43 AM, Tom de Vries <Tom_deVries@mentor.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> [ was: Re: [RFC] Dump function attributes ]
>>>>>
>>>>> On 28/09/15 17:17, Bernd Schmidt wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 09/28/2015 04:32 PM, Tom de Vries wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> patch below prints the function attributes in the dump file.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> foo ()
>>>>>>> [ noclone , noinline ]
>>>>>>> {
>>>>>>> ...
>>>>>>>
>>>>>>> Good idea?
>>>>>>>
>>>>>>> If so, do we want one attribute per line?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Only for really long ones I'd think. Patch is ok for now.
>>>>>>
>>>>>>
>>>>>
>>>>> Reposting patch with ChangeLog entry added.
>>>>>
>>>>> Bootstrapped and reg-tested on x86_64.
>>>>>
>>>>> Committed to trunk.
>>>>
>>>>
>>>>
>>>> Hmpf.  I always like to make the dump-files as much copy&past-able to
>>>> testcases
>>>> as possible.
>>>
>>>
>>>
>>> Hmm, interesting. Not something I use, but I can imagine it's useful.
>>>
>>>> So why did you invent a new syntax for attributes instead of using
>>>> the existing __attribute__(("noclone", "noinline")) (in this case)?
>>>
>>>
>>>
>>> My main concerns were:
>>> - being able to see in dump files what the actual attributes of a
>>>    function are (rather than having to figure it out in a debug session).
>>> - being able to write testcases that can test for the presence of those
>>>    attributes in dump files
>>>
>>>> Did you verify
>>>> how attributes with arguments get printed?
>>>
>>>
>>>
>>> F.i. an oacc offload function compiled by the host compiler is annotated
>>> as
>>> follows:
>>>
>>> before pass_oacc_transform (in the gomp-4_0-branch):
>>> ...
>>> [ oacc function 32, , , omp target entrypoint ]
>>> ...
>>>
>>> after pass_oacc_transform:
>>> ....
>>> [ oacc function 1, 1, 1, omp target entrypoint ]
>>> .
>>
>>
>> Hmm, ok.  So without some extra dump_attribute_list wrapping
>> __attribute_(( ... )) around the above doesn't make it more amenable
>> for cut&pasting.
>>
>
> With attached untested follow-up patch, for test-case:
> ...
> void __attribute__((noinline)) __attribute__((alias ("bar"), noclone))
> foo (void)
> {
>
> }
>
> void __attribute__ ((__target__ ("arch=core2", "sse3")))
> foo2 (void)
> {
>
> }
>
> void __attribute__ ((optimize ((1))))
> foo3 (void)
> {
>
> }
>
> void __attribute__ ((optimize (("1"))))
> foo4 (void)
> {
>
> }
> ...
>
> I get at gimple dump:
> ...
> __attribute__((noclone, alias ("bar"), noinline))
> foo ()
> {
>
> }
>
>
> __attribute__((__target__ ("arch=core2", "sse3")))
> foo2 ()
> {
>
> }
>
>
> __attribute__((optimize (1)))
> foo3 ()
> {
>
> }
>
>
> __attribute__((optimize ("1")))
> foo4 ()
> {
>
> }
> ...
>
> OK if bootstrap/regtest succeeds?

Ok.

Thanks,
Richard.

> Thanks,
> - Tom
>
diff mbox

Patch

Make dumping of function attributes resemble source syntax

---
 gcc/tree-cfg.c | 32 +++++++++++++++++++++++++-------
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index e06ee28..735ac46 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -72,6 +72,7 @@  along with GCC; see the file COPYING3.  If not see
 #include "tree-cfgcleanup.h"
 #include "wide-int-print.h"
 #include "gimplify.h"
+#include "attribs.h"
 
 /* This file contains functions for building the Control Flow Graph (CFG)
    for a function tree.  */
@@ -7352,6 +7353,30 @@  dump_function_to_file (tree fndecl, FILE *file, int flags)
 		  && decl_is_tm_clone (fndecl));
   struct function *fun = DECL_STRUCT_FUNCTION (fndecl);
 
+  if (DECL_ATTRIBUTES (fndecl) != NULL_TREE)
+    {
+      fprintf (file, "__attribute__((");
+
+      bool first = true;
+      tree chain;
+      for (chain = DECL_ATTRIBUTES (fndecl); chain;
+	   first = false, chain = TREE_CHAIN (chain))
+	{
+	  if (!first)
+	    fprintf (file, ", ");
+
+	  print_generic_expr (file, get_attribute_name (chain), dump_flags);
+	  if (TREE_VALUE (chain) != NULL_TREE)
+	    {
+	      fprintf (file, " (");
+	      print_generic_expr (file, TREE_VALUE (chain), dump_flags);
+	      fprintf (file, ")");
+	    }
+	}
+
+      fprintf (file, "))\n");
+    }
+
   current_function_decl = fndecl;
   fprintf (file, "%s %s(", function_name (fun), tmclone ? "[tm-clone] " : "");
 
@@ -7369,13 +7394,6 @@  dump_function_to_file (tree fndecl, FILE *file, int flags)
     }
   fprintf (file, ")\n");
 
-  if (DECL_ATTRIBUTES (fndecl) != NULL_TREE)
-    {
-      fprintf (file, "[ ");
-      print_generic_expr (file, DECL_ATTRIBUTES (fndecl), dump_flags);
-      fprintf (file, "]\n");
-    }
-
   if (flags & TDF_VERBOSE)
     print_node (file, "", fndecl, 2);
 
-- 
1.9.1