This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Splitting up gcc/omp-low.c?
- From: Martin Jambor <mjambor at suse dot cz>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Bernd Schmidt <bschmidt at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 8 Apr 2016 12:46:16 +0200
- Subject: Re: Splitting up gcc/omp-low.c?
- Authentication-results: sourceware.org; auth=none
- References: <20151207111758 dot GA24234 at virgil dot suse dot cz> <20151207112243 dot GF24234 at virgil dot suse dot cz> <20151209131930 dot GS5675 at tucnak dot redhat dot com> <87si3b4mk3 dot fsf at kepler dot schwinge dot homeip dot net> <5668638A dot 5030500 at redhat dot com> <20151210080835 dot GX5675 at tucnak dot redhat dot com> <87y48o5toc dot fsf at hertz dot schwinge dot homeip dot net>
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 <jakub@redhat.com> 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