Re: GSOC

[nick <xerofoify at gmail dot com>]

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