From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114339 invoked by alias); 30 Sep 2015 12:00:39 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 114204 invoked by uid 89); 30 Sep 2015 12:00:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 30 Sep 2015 12:00:37 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42367) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ZhG3n-0005yo-3H for gcc-patches@gnu.org; Wed, 30 Sep 2015 08:00:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhG3l-00081p-KJ for gcc-patches@gnu.org; Wed, 30 Sep 2015 08:00:34 -0400 Received: from mail-yk0-x22f.google.com ([2607:f8b0:4002:c07::22f]:34749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhG3l-00081i-F1 for gcc-patches@gnu.org; Wed, 30 Sep 2015 08:00:33 -0400 Received: by ykdg206 with SMTP id g206so37804405ykd.1 for ; Wed, 30 Sep 2015 05:00:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.57.80 with SMTP id 77mr2454896ykz.59.1443614429967; Wed, 30 Sep 2015 05:00:29 -0700 (PDT) Received: by 10.37.93.136 with HTTP; Wed, 30 Sep 2015 05:00:29 -0700 (PDT) In-Reply-To: <560BB354.5040404@mentor.com> References: <56094F9A.1040500@mentor.com> <56095A0A.40102@redhat.com> <560A24E7.8060908@mentor.com> <560A74BF.8080509@mentor.com> <560BB354.5040404@mentor.com> Date: Wed, 30 Sep 2015 12:37:00 -0000 Message-ID: Subject: Re: [patch, committed] Dump function attributes From: Richard Biener To: Tom de Vries Cc: Bernd Schmidt , "gcc-patches@gnu.org" Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::22f X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg02325.txt.bz2 On Wed, Sep 30, 2015 at 12:03 PM, Tom de Vries wrote: > On 29/09/15 13:29, Richard Biener wrote: >> >> On Tue, Sep 29, 2015 at 1:23 PM, Tom de Vries >> wrote: >>> >>> On 29/09/15 12:36, Richard Biener wrote: >>>> >>>> >>>> On Tue, Sep 29, 2015 at 7:43 AM, Tom de Vries >>>> 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 >