On 4 September 2015 at 17:44, Jeff Law <l...@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.
