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
