This is the mail archive of the
mailing list for the GCC project.
Fwd: incremental compiler project
- From: David Kunsman <dmkunsman at gmail dot com>
- To: GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 4 Sep 2015 11:51:21 -0500
- Subject: Fwd: incremental compiler project
- Authentication-results: sourceware.org; auth=none
- References: <CAPVyUPD0eAyAuPOktpjqpY=UKx0t2YEvFQxMUMY2Lv2pwUAjLA at mail dot gmail dot com> <55E87708 dot 7010901 at gmail dot com> <87twrap6c2 dot fsf at tromey dot com> <CAPVyUPDX9YiCSp8WjafmuYpwAqx4jt-2r_7U4XXO4Zg_HmuzgQ at mail dot gmail dot com> <55E9BC4E dot 5040508 at redhat dot com> <CAESRpQBtfCPa7crX2ng_GaQVRRe5t7KC=7AA_9cca9bKN1hUaw at mail dot gmail dot com> <CAPVyUPB0wbQomrMggib-YboupcXzZiPA8yan0tcHLYxBte6pPg at mail dot 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 <firstname.lastname@example.org> 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
> <email@example.com> wrote:
>> On 4 September 2015 at 17:44, Jeff Law <firstname.lastname@example.org> 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