From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71676 invoked by alias); 28 Mar 2019 08:44:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 71596 invoked by uid 89); 28 Mar 2019 08:44:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lf1-f46.google.com Received: from mail-lf1-f46.google.com (HELO mail-lf1-f46.google.com) (209.85.167.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Mar 2019 08:44:21 +0000 Received: by mail-lf1-f46.google.com with SMTP id g7so13352950lfh.10 for ; Thu, 28 Mar 2019 01:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GV0QUCUc6L+U/SNqWV07raGut1u6IOAYuaqoH3WniO4=; b=ScejZqfiFD1afeK658KIKpr0DDGlyS8JNU3OlrlDemlK3z5+kVFF/ILWpnkYTwI5pG MC3aUqGcb0EuvqK5eEOEHi5mPp1ODCAm777WRXTiBHujBlkakpKGeniQQu8RfYB+r8OW oZ1fTFEYtWK/Xk+4xcGMOV+CkIvW7vjnl6nWOpcJ4ijw/AW/5aWQ0oDgp6gOuHl7zWOQ OKoOuDLgY2pcNlm3ZE7NRUEFitnYHj9X31ZXrNXhmtKuvvS8oHgoWBo1ep/KryvYdUWe FHcQ/3Mn0L1fBqDLLP2qaqT3BGnw7gke7uceSaZWBaE4gZsT02EvxA08Ex13LB+xc2HS IbmA== MIME-Version: 1.0 References: <176a02b4-ed71-4a42-fb76-09570f303991@gmail.com> <1553607171.18132.95.camel@redhat.com> <20190327135515.qsu7kka5mukw375e@smtp.gmail.com> In-Reply-To: From: Richard Biener Date: Thu, 28 Mar 2019 08:44:00 -0000 Message-ID: Subject: Re: GSOC To: nick Cc: Giuliano Belinassi , Richard Biener , David Malcolm , GCC Development , Martin Jambor Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00245.txt.bz2 On Wed, Mar 27, 2019 at 3:43 PM nick wrote: > > > > On 2019-03-27 9:55 a.m., Giuliano Belinassi wrote: > > Hi, > > > > On 03/26, Richard Biener wrote: > >> On Tue, 26 Mar 2019, David Malcolm wrote: > >> > >>> On Mon, 2019-03-25 at 19:51 -0400, nick wrote: > >>>> Greetings All, > >>>> > >>>> I would like to take up parallelize compilation using threads or make > >>>> c++/c > >>>> memory issues not automatically promote. I did ask about this before > >>>> but > >>>> not get a reply. When someone replies I'm just a little concerned as > >>>> my writing for proposals has never been great so if someone just > >>>> reviews > >>>> and doubt checks that's fine. > >>>> > >>>> As for the other things building gcc and running the testsuite is > >>>> fine. Plus > >>>> I already working on gcc so I've pretty aware of most things and this > >>>> would > >>>> be a great steeping stone into more serious gcc development work. > >>>> > >>>> If sample code is required that's in mainline gcc I sent out a trial > >>>> patch > >>>> for this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395 > >>>> > >>>> Cheers, > >>>> > >>>> Nick > >>> > >>> It's good to see that you've gotten as far as attaching a patch to BZ > >>> [1] > >>> > >>> I think someone was going to attempt the "parallelize compilation using > >>> threads" idea last year, but then pulled out before the summer; you may > >>> want to check the archives (or was that you?) > >> > >> There's also Giuliano Belinassi who is interested in the same project > >> (CCed). > > > > Yes, I will apply for this project, and I will submit the final version > > of my proposal by the end of the week. > > > > Currently, my target is the `expand_all_functions` routine, as most of > > the time is spent on it according to the experiments that I performed as > > part of my Master's research on compiler parallelization. > > (-O2, --disable-checking) > > > > Thank you, > > Giuliano. > > > > > My goal was this: > Or maybe a project to be more > explicit about regions of the code that assume that the garbage- > collector can't run within them?[3] (since the GC is state that would > be shared by the threads). That's already pretty clear so a non-project. Honestly you are somewhat late to the project but if you can come up with a solid proposal we will definitely have a look. The project itself is of course large enough to cover 10s of GSoC students ;) Richard. > So there is no conflict between me and Giuliano. Richard and me have > already been going back and forth. The remaining tasks for me are > just write the proposal as the big one and I asked Richard to sent > me a example you guys liked. I've signed up to contribute for the > last year so that's fine. > > Just letting the list known as well as Richard where I am, > > Nick > >> > >>> IIRC Richard [CCed] was going to mentor, with me co-mentoring [2] - but > >>> I don't know if he's still interested/able to spare the cycles. > >> > >> I've offered mentoring to Giuliano, so yes. > >> > >>> That said, the parallel compilation one strikes me as very ambitious; > >>> it's not clear to me what could realistically be done as a GSoC > >>> project. I think a good proposal on that would come up with some > >>> subset of the problem that's doable over a summer, whilst also being > >>> useful to the project. The RTL infrastructure has a lot of global > >>> state, so maybe either focus on the gimple passes, or on fixing global > >>> state on the RTL side? (I'm not sure) > >> > >> That was the original intent for the experiment. There's also > >> the already somewhat parallel WPA stage in LTO compilation mode > >> (but it simply forks for the sake of simplicity...). > >> > >>> Or maybe a project to be more > >>> explicit about regions of the code that assume that the garbage- > >>> collector can't run within them?[3] (since the GC is state that would > >>> be shared by the threads). > >> > >> The GC will be one obstackle. The original idea was to drive > >> parallelization on the pass level by the pass manager for the > >> GIMPLE passes, so serialization points would be in it. > >> > >> Richard. > >> > >>> Hope this is constructive/helpful > >>> Dave > >>> > >>> [1] though typically our workflow involved sending patches to the gcc- > >>> patches mailing list > >>> [2] as libgccjit maintainer I have an interest in global state within > >>> the compiler > >>> [3] I posted some ideas about this back in 2013 IIRC; probably > >>> massively bit-rotted since then. I also gave a talk at Cauldron 2013 > >>> about global state in the compiler (with a view to gcc-as-a-shared- > >>> library); likewise I expect much of the ideas there to be out-of-date); > >>> for libgccjit I went with a different approach