From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30220 invoked by alias); 8 Apr 2016 10:46:22 -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 30197 invoked by uid 89); 8 Apr 2016 10:46:21 -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,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Someone, late X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 08 Apr 2016 10:46:20 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E67C2AB9D; Fri, 8 Apr 2016 10:46:15 +0000 (UTC) Date: Fri, 08 Apr 2016 10:46:00 -0000 From: Martin Jambor To: Thomas Schwinge Cc: Jakub Jelinek , Bernd Schmidt , gcc-patches@gcc.gnu.org Subject: Re: Splitting up gcc/omp-low.c? Message-ID: <20160408104616.GJ13833@virgil.suse.cz> Mail-Followup-To: Thomas Schwinge , Jakub Jelinek , Bernd Schmidt , gcc-patches@gcc.gnu.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87y48o5toc.fsf@hertz.schwinge.homeip.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00390.txt.bz2 Hi, On Fri, Apr 08, 2016 at 11:36:03AM +0200, Thomas Schwinge wrote: > Hi! > > 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: > > > > > > > >In addition to that, 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? Or, can you > > > >tell already that there would be too many cross-references between the > > > >several files to make this infeasible? > > > > > > It would be nice to get rid of all the code duplication in that file. That > > > alone could reduce the size by quite a bit, and hopefully make it easier to > > > read. > > > > What exact code duplication do you mean? > > (Has been discussed in the following.) At this point, I do not intend to > work on any kinds of cleanup, but rather just the "mechanical" changes: > > > > I suspect a split along the ompexp/omplow boundary would be quite easy to > > > achieve. > > > > Yeah, that might be the possible splitting boundary (have omp-low.c, > > omp-exp.c). > > Right. And possibly some kind of omp-simd.c, and omp-checking.c, and so > on, if feasible. (I have not yet looked in detail.) > > > > >I'd suggest to do this shortly before GCC 6 is released, so that > > > >backports from trunk to gcc-6-branch will be easy. (I assume we don't > > > >have to care for gcc-5-branch backports too much any longer.) > > > > > > I'll declare myself agnostic as to whether such a change is appropriate for > > > gcc-6 at this stage. I guess it kind of depends on the specifics. > > > > Certainly. On one side I'd say it is too late now in stage3, on the other > > side when would be better time to do that, during stage1 people will have > > more likely out of the tree branches with more changes (I'm aware we even > > now have the HSA, OpenMP -> PTX and OpenACC branches). > > > > So, if somebody wants to try that, we can see if the result would be > > appropriate. > > So, has time now come to execute this task? (To remind: the idea > explicitly has been to do this late, shortly before the gcc-6-branch gets > created, to make it easy in the following months to apply patches to both > trunk and gcc-6-branch.) > Unless someone is quicler, I can give it a go next Thursday (not any sooner, unfortunately). I would do a division into omp-low.c and omp-exp.c and possibly an omp.c for simple stuff not fitting anywhere else and perhaps even a separate omp-gridify.c. Someone else would have to put stuff into an omp-simd.c, I'm afraid. But it we can go about this incrementaly. Thanks, Martin