From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89617 invoked by alias); 25 May 2016 06:04:01 -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 89478 invoked by uid 89); 25 May 2016 06:03:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3429, answered, diego, Diego 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 25 May 2016 06:03:49 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1b5Rv0-00059D-Ge from Thomas_Schwinge@mentor.com ; Tue, 24 May 2016 23:03:46 -0700 Received: from hertz.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Wed, 25 May 2016 07:03:45 +0100 From: Thomas Schwinge To: Bernd Schmidt , Jakub Jelinek , CC: Martin Jambor Subject: Re: Splitting up gcc/omp-low.c? In-Reply-To: <87inybvbgy.fsf@hertz.schwinge.homeip.net> References: <20151207111758.GA24234@virgil.suse.cz> <20151207112243.GF24234@virgil.suse.cz> <20151209131930.GS5675@tucnak.redhat.com> <87si3b4mk3.fsf@kepler.schwinge.homeip.net> <5668638A.5030500@redhat.com> <20151210080835.GX5675@tucnak.redhat.com> <87y48o5toc.fsf@hertz.schwinge.homeip.net> <87twj54hx6.fsf@hertz.schwinge.homeip.net> <87shxzxz68.fsf@hertz.schwinge.homeip.net> <87inykwvyp.fsf@hertz.schwinge.homeip.net> <87inybvbgy.fsf@hertz.schwinge.homeip.net> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 25 May 2016 09:17:00 -0000 Message-ID: <87y46ysmgy.fsf@hertz.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-05/txt/msg01991.txt.bz2 Hi! Ping. Given that we conceptually agreed about this task, but apparently nobody is now interested in reviewing my proposed changes (and tells me how they'd like me to submit the patch for review), should I maybe just execute the steps? On Wed, 18 May 2016 13:42:37 +0200, Thomas Schwinge wrote: > Ping. >=20 > On Wed, 11 May 2016 15:44:14 +0200, I wrote: > > Ping. > >=20 > > On Tue, 03 May 2016 11:34:39 +0200, I wrote: > > > On Wed, 13 Apr 2016 18:01:09 +0200, I wrote: > > > > On Fri, 08 Apr 2016 11:36:03 +0200, I wrote: > > > > > On Thu, 10 Dec 2015 09:08:35 +0100, Jakub Jelinek wrote: > > > > > > On Wed, Dec 09, 2015 at 06:23:22PM +0100, Bernd Schmidt wrote: > > > > > > > On 12/09/2015 05:24 PM, Thomas Schwinge wrote: > > > > > > > >how about we split up gcc/omp-low.c into several > > > > > > > >files? Would it make sense (I have not yet looked in detail= ) to do so > > > > > > > >along the borders of the several passes defined therein? > > > >=20 > > > > > > > I suspect a split along the ompexp/omplow boundary would be q= uite easy to > > > > > > > achieve. > > > >=20 > > > > That was indeed the first one that I tackled, omp-expand.c (spelled= out > > > > "expand" instead of "exp" to avoid confusion as "exp" might also be= short > > > > for "expression"; OK?) [...] > > >=20 > > > That's the one I'd suggest to pursue next, now that GCC 6.1 has been > > > released. How would you like me to submit the patch for review? (It= 's > > > huge, obviously.) > > >=20 > > > A few high-level comments, and questions that remain to be answered: > > >=20 > > > > Stuff that does not relate to OMP lowering, I did not move stuff ou= t of > > > > omp-low.c (into a new omp.c, or omp-misc.c, for example) so far, but > > > > instead just left all that in omp-low.c. We'll see how far we get. > > > >=20 > > > > One thing I noticed is that there sometimes is more than one suitab= le > > > > place to put stuff: omp-low.c and omp-expand.c categorize by compil= er > > > > passes, and omp-offload.c -- at least in part -- [would be] about t= he orthogonal > > > > "offloading" category. For example, see the OMPTODO "struct oacc_l= oop > > > > and enum oacc_loop_flags" in gcc/omp-offload.h. We'll see how that= goes. > > >=20 > > > > Some more comments, to help review: > > >=20 > > > > As I don't know how this is usually done: is it appropriate to remo= ve > > > > "Contributed by Diego Novillo" from omp-low.c (he does get mentione= d for > > > > his OpenMP work in gcc/doc/contrib.texi; a ton of other people have= been > > > > contributing a ton of other stuff since omp-low.c has been created)= , or > > > > does this line stay in omp-low.c, or do I even duplicate it into th= e new > > > > files? > > > >=20 > > > > I tried not to re-order stuff when moving. But: we may actually wa= nt to > > > > reorder stuff, to put it into a more sensible order. Any suggestio= ns? > > >=20 > > > > I had to export a small number of functions (see the prototypes not= moved > > > > but added to the header files). > > > >=20 > > > > Because it's also used in omp-expand.c, I moved the one-line static > > > > inline is_reference function from omp-low.c to omp-low.h, and renam= ed it > > > > to omp_is_reference because of the very generic name. Similar func= tions > > > > stay in omp-low.c however, so they're no longer defined next to each > > > > other. OK, or does this need a different solution? Gr=C3=BC=C3=9Fe Thomas