Fwd: incremental compiler project

[David Kunsman <dmkunsman at gmail dot com>]

I was just looking to get into a project...and the incremental project
caught my eye....wondering if it even practical due to the branch is
over 6 years old...and merging everything with the current trunk would
be a job.  It seems like many of the projects on the wiki are out of
date.  Does anybody know a current project that needs major help?  I
would be more than happy to work on it.

On Fri, Sep 4, 2015 at 11:37 AM, David Kunsman <dmkunsman@gmail.com> wrote:
> I was just looking to get into a project...and the incremental project
> caught my eye....wondering if it even practical due to the branch is
> over 6 years old...and merging everything with the current trunk would
> be a job.  It seems like many of the projects on the wiki are out of
> date.  Does anybody know a current project that needs major help?  I
> would be more than happy to work on it.
>
> On Fri, Sep 4, 2015 at 11:31 AM, Manuel LÃpez-IbÃÃez
> <lopezibanez@gmail.com> wrote:
>> On 4 September 2015 at 17:44, Jeff Law <law@redhat.com> wrote:
>>> On 09/04/2015 09:40 AM, David Kunsman wrote:
>>>>
>>>> what do you think about the sub project in the wiki:
>>>>
>>>> Parallel Compilation:
>>>>
>>>> One approach is to make the front end multi-threaded. (I've pretty
>>>> much abandoned this idea. There are too many mutable tree fields,
>>>> making this a difficult project. Also, threads do not interact well
>>>> with fork, which is currently needed by the code generation approach.)
>>>
>>> You should get in contact with David Malcolm as these issues are directly
>>> related to his JIT work.
>>
>> See https://gcc.gnu.org/wiki/JIT
>>
>> If I remember correctly from past discussions, making the C/C++ FEs
>> multi-threaded is not really desired. People already compile multiple
>> files in parallel using 'make -j' and it is expected that many
>> bottlenecks would require sequential execution anyway. Adding locks
>> within the FEs may make them slower rather than faster.
>>
>> However, making the FEs thread-safer would be great for JIT and for
>> converting them into reusable libraries (or if someone comes up with a
>> feasible GCC server design).
>>
>>>> This will entail removing most global variables, marking some with
>>>> __thread, and wrapping a few with locks.
>>>
>>> Yes, but that's work that is already in progress.  Right now David's got a
>>> big log and context switch in place, but we really want to drive down the
>>> amount of stuff in that context switch.
>>
>> Removing global variables would already be a big help. For example,
>> most flag_* global variables (example: flag_no_line_commands) can be
>> encoded in struct gcc_options and could be removed. This would be a
>> small project to start with, since one can do the conversion one at a
>> time.
>>
>> Cheers,
>>
>> Manuel.