This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Parallelize GCC with Threads -- First Evaluation
Hi
On 06/24, nick wrote:
>
>
> On 2019-06-24 8:59 a.m., Giuliano Belinassi wrote:
> > Hi,
> >
> > Parallelize GCC with Threads -- First Evaluation
> >
> > Hi everyone,
> >
> > I am attaching the first evaluation report here publicly for gathering
> > feedback. The file is in markdown format and it can be easily be converted to
> > PDF for better visualization.
> >
> > I am also open to suggestions and ideas in order to improve the current project :-)
> >
> > My branch can be seen here: https://gitlab.com/flusp/gcc/tree/giulianob_parallel
> >
> > Giuliano
> >
>
> Guiliano,
>
> Three things first your original proposal was just for expand_all_functions so don't
> know if it's extended out now but there's other parts in my research so the title
> was a little confusing.
Everything that I am doing is to parallelize this function. Notice that
in trunk there is a call to node->expand(), and in order to expand two
nodes in parallel I have to explore all shared states inside these,
including the passes. Also my work until now is focused in GIMPLE.
>
> I'm assuming this is outside the scope of the current project but does your all_rtl_passes
> function help out with architecture specific tuning flags as it seems that my research
> states that's one area of shared state.
Sorry, but I am not sure if I understeand what you meant. When splitting
all_passes into all_passes and all_rtl_passes, I didn't touch it and I
am assuming it is working as all tests except three which I told Richard
are passing. As for tuning flags, I documented a few of then but I am
currently ignoring it since I marked it as backend dependency.
>
> In addition for memory this may be really hard to do but can you have a signaler
> that tells each phase what data to pass on therefore notifying what needs to be
> passed on to the next pass. So if expand_all_functions needs to pass x the signaler
> will notify the pass and just swap the values into the pass lock less if possible
> or just kill it off if not. This would mean writing a GENERIC to RTL final passes
> signaler which may take too long considering the scope of the project.
I am assuming you are talking about the pass-pipeline approach Richi
recommended to avoid the per-pass global-states. I don't think a signal
is a good idea here as we can lose signals around if we are not careful
enough. What I would do is to use a producer-consumer queue on each
pass, passing the function to optimize and a struct whith everything the
pass needs. Or protect the global states with a binary semaphore: when the
pass is running, it decrements the semaphore, and increments it after it
works is done. When the previous pass wants to send information, I
decrement the semaphore, change the variables, and increment it again.
This is pretty similar of how a mutex work.
>
> Again that's just off the top of my head so it may be a really bad idea,
>
> Nick
>
> P.S. Good luck through.
Thank you,
Giuliano