Re: GSOC

[nick <xerofoify at gmail dot com>]

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