This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Parallelize GCC with Threads -- First Evaluation
- From: nick <xerofoify at gmail dot com>
- To: Giuliano Belinassi <giuliano dot belinassi at usp dot br>, gcc at gcc dot gnu dot org, rguenther at suse dot de
- Date: Mon, 24 Jun 2019 15:42:03 -0400
- Subject: Re: Parallelize GCC with Threads -- First Evaluation
- References: <20190624125941.q56xavlondppbwrs@smtp.gmail.com>
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.
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.
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.
Again that's just off the top of my head so it may be a really bad idea,
Nick
P.S. Good luck through.