From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77951 invoked by alias); 26 Mar 2019 13:59:59 -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 77925 invoked by uid 89); 26 Mar 2019 13:59:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-qt1-f194.google.com Received: from mail-qt1-f194.google.com (HELO mail-qt1-f194.google.com) (209.85.160.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Mar 2019 13:59:56 +0000 Received: by mail-qt1-f194.google.com with SMTP id y36so14652231qtb.3 for ; Tue, 26 Mar 2019 06:59:56 -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=AoJBEaR23JASauZNE2T7WaQmNrDVy2dU5chv8XPrs0Y=; b=KR6N8vb6sQUowKTmSJxdt+IWJJFI0edBCB1fub18M34LcPF1Y+mIIsssxDU8ExAteT 7pu91F2739u+REIiLjcm39cOR1lvCPCeVRshoiW7rT2WV71q6HU43kV5Gly4ogzuFmjr pe9QUONaoCI3sKgiRG2tljhpYrzNsAd2XfE6aepw2kHSCHnK0pRV/CrWW5CNcQI2Uosi uz1x/AKlBd88uo76C3RRfiJCCIixYBmMDofvub+fYQgyXB6kpFn2pItthfhFRY+hRf9F oWXQNXTIYpeJjtrucsNMU5qYz6j5tbnMmzApZIfjJS3nrm557xAIiXVss1AtEyyJxTwD gdnQ== 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 c50sm583102qtd.60.2019.03.26.06.59.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 06:59:53 -0700 (PDT) Subject: Re: GSOC To: Richard Biener , David Malcolm Cc: GCC Development , mjambor@suse.cz, Giuliano Belinassi References: <176a02b4-ed71-4a42-fb76-09570f303991@gmail.com> <1553607171.18132.95.camel@redhat.com> From: nick Message-ID: <661349e6-efeb-79dc-9a89-f3454b511b22@gmail.com> Date: Tue, 26 Mar 2019 13:59: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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00215.txt.bz2 On 2019-03-26 9:41 a.m., 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). > >> 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 was just there because it was assumed wrong by me. I sent a proposed probably correct patch to the gcc patches list without a commit message as I wanted to make sure it was correct first. This is the said patch: >From a5fcad0cd1d1b79606ad9cec9a37d6a77ee50fc8 Mon Sep 17 00:00:00 2001 From: Nicholas Krause Date: Sun, 24 Mar 2019 15:07:18 -0400 Subject: [PATCH] Proposed patch to fix bug id, 89796 on bugzilla Not sure if this is a correct fix to this bug found here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but comments are welcome. If a backtrace is required please let me know. I am just sending it to the development list for review to make sure it's OK in terms of my understanding the code. Signed-off-by: Nicholas Krause --- gcc/cp/constraint.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc index 9884eb0db50..a78d0a9a49b 100644 --- a/gcc/cp/constraint.cc +++ b/gcc/cp/constraint.cc @@ -1882,7 +1882,7 @@ tsubst_requires_expr (tree t, tree args, tree parms = TREE_OPERAND (t, 0); if (parms) { - parms = tsubst_constraint_variables (parms, args, complain, in_decl); + parms = tsubst_constraint_variables (PARM_CONSTR_PARMS (parms), args, complain, in_decl); if (parms == error_mark_node) return error_mark_node; } -- 2.17.1 >> 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 would make the most sense I think in terms of making this better as shared state would normally slow this down. Nick > 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