From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27445 invoked by alias); 20 Nov 2013 01:12:00 -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 27419 invoked by uid 89); 20 Nov 2013 01:11:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-wi0-f175.google.com Received: from Unknown (HELO mail-wi0-f175.google.com) (209.85.212.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 20 Nov 2013 01:11:58 +0000 Received: by mail-wi0-f175.google.com with SMTP id hi5so1520075wib.8 for ; Tue, 19 Nov 2013 17:11:49 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.210.237 with SMTP id mx13mr21011638wic.4.1384909909535; Tue, 19 Nov 2013 17:11:49 -0800 (PST) Received: by 10.217.119.193 with HTTP; Tue, 19 Nov 2013 17:11:49 -0800 (PST) In-Reply-To: References: <20121221064539.0E1A7100704@rong.mtv.corp.google.com> <20121221092532.GA7055@kam.mff.cuni.cz> <50EB31B7.9090307@redhat.com> Date: Wed, 20 Nov 2013 07:20:00 -0000 Message-ID: Subject: Re: atomic update of profile counters (issue7000044) From: Andrew Pinski To: Rong Xu Cc: Richard Henderson , Richard Biener , Xinliang David Li , Jan Hubicka , GCC Patches , reply@codereview.appspotmail.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg02447.txt.bz2 On Tue, Nov 19, 2013 at 5:02 PM, Rong Xu wrote: > Hi all, > > I merged this old patch with current trunk. I also make the following changes > (1) not using weak references. Now every *profile_atomic() has it's > own .o so that none of them will be in the final binary if > -fprofile-generate-atomic is not specified. > (2) more value profilers have the atomic version. > (3) not link to libatomic. I used to link the libatomic in the > presence of -fprofile-generate-atomic, per Andrew's suggestion. It > used to work. But now if I can add -latomic in the SPEC, it cannot > find the libatomic.so.1 (unless I specify the PATH). I did not find an > easy way to statically link libatomic.a. Andrew: Do you have any > suggestion? Or should we let the user link to libatomic.a if the > builtins are not expanded? It should work for an installed GCC. For testing you might need something that is included inside testsuite/lib/atomic-dg.exp which sets the library path to include libatomic build directory. I think now we require libatomic in more cases (C11 atomic support for an example). Thanks, Andrew Pinski > > Is this OK for trunk? > > Thanks, > > -Rong > > On Mon, Jan 7, 2013 at 12:55 PM, Rong Xu wrote: >> Function __gcov_indirect_call_profiler_atomic (which contains call to >> the atomic function) is always emitted in libgcov. >> Since we only link libatomic when -fprofile-gen-atomic is specified, >> we have to make the atomic function weak -- otherwise, there is a >> unsat for regular FDO gen build (of course, when the builtin is not >> expanded). >> >> An alternative it to always link libatomic together with libgcov. Then >> we don't need the weak stuff. I'm not sure when one is better. >> >> -Rong >> >> On Mon, Jan 7, 2013 at 12:36 PM, Richard Henderson wrote: >>> On 01/03/2013 04:42 PM, Rong Xu wrote: >>>> It links libatomic when -fprofile-gen-atomic is specified for FDO >>>> instrumentation build. Here I assume libatomic is always installed. >>>> Andrew: do you think if this is reasonable? >>>> >>>> It also disables the functionality if target does not support weak >>>> (ie. TARGET_SUPPORTS_WEAK == 0). >>> >>> Since you're linking libatomic, you don't need weak references. >>> >>> I think its ok to assume libatomic is installed, given that the >>> user has had to explicitly use the command-line option. >>> >>> >>> r~