On 2019-06-25 9:40 a.m., Giuliano Belinassi wrote:
> 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.
>
Exactly that's fine, it's been part of my research these days when I've had
time. If you pass the documentation of which backend passes are not getting
touched still that would be great as I'm going to inspect those later this
week probably. IPA as your finding out now and SSA lowering seem to have
issues too so I'm going to look into through as well.
>>
>> 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.
>
>>
That was basically my idea fleshed out so it's fine now.
>> 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
>
Sorry for not being clearer,
Nick
