From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81777 invoked by alias); 17 Jun 2019 17:24:58 -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 78421 invoked by uid 89); 17 Jun 2019 17:24:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=pieces X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jun 2019 17:24:48 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1hcvN8-0002bv-NR from Thomas_Schwinge@mentor.com for gcc-patches@gcc.gnu.org; Mon, 17 Jun 2019 10:24:46 -0700 Received: from hertz.schwinge.homeip.net (137.202.0.90) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 17 Jun 2019 18:24:43 +0100 From: Thomas Schwinge To: Kwok Cheung Yeung CC: Catherine Moore , Subject: Re: [PATCH, og9] Port OpenACC profiling interface to OG9 In-Reply-To: References: User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/25.2.2 (x86_64-pc-linux-gnu) Date: Mon, 17 Jun 2019 17:24:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-06/txt/msg00976.txt.bz2 Hi Kwok! On Mon, 17 Jun 2019 14:27:46 +0100, Kwok Cheung Yeung wrote: > This is a straightforward port of the OpenACC profiling interface from=20 > OG8 to OG9, with a few tweaks Thanks for looking into this. > to compensate for patches that have not=20 > been carried over to OG9. Conceptually ACK. (I have not reviewed what's missing/got dropped.) > I have also bundled in the profiling hooks and=20 > documentation updates that have been added since the original patch in OG= 8. ACK. > Okay to push to openacc-gcc-9-branch? What you probably didn't know (sorry!) is that trunk r271346, , contains some changes that are not in the og8 code: code and documentation improvements, TODOs resolved, etc. It also doesn't contain the actual 'acc_register_library' implementation, because that one needs further work, as discussed before. I think what would be best, is the following approach: - First, backport trunk r271346 to og9. That might not be completely trivial, because as you know, og9 contains a number of "feature" commits that need to include changes related to the profiling code. It's the question in which order to sequence patches -- whether these changes related to the profiling code are part of the individual "feature" commits, or they're part of a later "profiling" commit. As og9 has been published with "feature" commits not containing any profiling bits, all these things will have to be in a later "profiling" commit. However, for upstreaming this into trunk later on, it will be beneficial to have the backported "profiling" commit as similar as possible to trunk r271346, so we shall live with some short-lived inconsistencies, maybe even a few testuite regressions, which then get resolved when you... - Second, on top of that, add the pieces of functionality (from the og8) version that are missing from the trunk r271346 backport. Of course, remove all changes that would worsen the state, compared to what trunk r271346 already contains. So, conceptually: a first commit to backport trunk r271346, then a second commit containing a merger of a (temporary) revert of the first commit followed by applying the patch you just posted. Then, remove from the second commit all changes that worsen the state, compared to what trunk r271346 already contains. Or, in other words: split the patch you just posted into two, where the first one is as close as possible to a backport of trunk r271346, then all other changes in a second commit. Will that work? I'll be happy to help review these changes, especially whether something should be part of the second commit, or get dropped. Gr=C3=BC=C3=9Fe Thomas