Re: GSOC

[Richard Biener <rguenther@suse.de>]

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 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