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 <xerofo...@gmail.com> 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 <xerofo...@gmail.com> --- 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
