From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83805 invoked by alias); 27 Mar 2019 14:43:43 -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 83796 invoked by uid 89); 27 Mar 2019 14:43:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.0 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-qt1-f175.google.com Received: from mail-qt1-f175.google.com (HELO mail-qt1-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Mar 2019 14:43:41 +0000 Received: by mail-qt1-f175.google.com with SMTP id h39so19135897qte.2 for ; Wed, 27 Mar 2019 07:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lDWYC7dKzXscgW3ZbJg9uPXSI04eFJ2WhITBv0ybC4E=; b=kNi5+I6H0k5Iru8MX+7rrCxxz8lAoBFBAXruhM5AjG2x6EhLhvXIBBwZYAeXcLQoF8 JwoTujHW3L3jgLB4gc3zd5s4YLfJp2XrYCjBV+I+ib0u7AT0xj786p1eBRDaPUpPFaZc DdgLX/muavHePeYY22yik0bYX55ns4TxjzE1PK51QeEx1K8eFur2Nkv13foWPKrapBZr DQPAcn9c1ZSgE56l78n07cdaR8hyBHvdnopmyqH/dLiNvKNnkLCHiL0rcxo65tNsiiJi iwyBE7p1I3S9nV5PFTbrRDw7Ab1bDfPmGX6E8uK0mSjZ4IWXStayPt0B0r+Gf9i0zQsu zzHQ== Return-Path: Received: from [192.168.1.101] (173-230-163-230.cable.teksavvy.com. [173.230.163.230]) by smtp.googlemail.com with ESMTPSA id w8sm9869343qki.54.2019.03.27.07.43.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 07:43:38 -0700 (PDT) Subject: Re: GSOC To: Giuliano Belinassi , Richard Biener Cc: David Malcolm , GCC Development , mjambor@suse.cz References: <176a02b4-ed71-4a42-fb76-09570f303991@gmail.com> <1553607171.18132.95.camel@redhat.com> <20190327135515.qsu7kka5mukw375e@smtp.gmail.com> From: nick Message-ID: Date: Wed, 27 Mar 2019 14:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190327135515.qsu7kka5mukw375e@smtp.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00239.txt.bz2 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). 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