| Message ID | 560A24E7.8060908@mentor.com |
|---|---|
| State | New |
| Headers | show |
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. So why did you invent a new syntax for attributes instead of using the existing __attribute__(("noclone", "noinline")) (in this case)? Did you verify how attributes with arguments get printed? Thanks, Richard. > > Thanks, > - Tom
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 ] ... Thanks, - Tom
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. Richard. > > Thanks, > - Tom
Dump function attributes 2015-09-29 Tom de Vries <tom@codesourcery.com> * tree-cfg.c (dump_function_to_file): Dump function attributes. --- gcc/tree-cfg.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c index 807d96f..08935ac 100644 --- a/gcc/tree-cfg.c +++ b/gcc/tree-cfg.c @@ -7369,6 +7369,13 @@ 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