Re: incremental compiler project

[Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>]

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.