On Wed, Mar 27, 2019 at 3:43 PM nick <xerofo...@gmail.com> 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
