This is the mail archive of the
mailing list for the GCC project.
Re: Multi-Threading GCC Compiler Internal Data
- From: Richard Biener <rguenther at suse dot de>
- To: Nicholas Krause <xerofoify at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 17 Sep 2019 08:37:07 +0200 (CEST)
- Subject: Re: Multi-Threading GCC Compiler Internal Data
- References: <email@example.com>
On Mon, 16 Sep 2019, Nicholas Krause wrote:
> Greetings Richard,
> I don't know if it's currently possible but whats the best way to either so
> about or
> use a tool to expose shared state at both the GIMPLE and RTL level. This
> allow us to figure out much better what algorthims or data structures to
> to allow this to scale much better than the current prototype.
You are mixing independent issues. Shared state needs to be identified
and protected for correctness reasons. In some cases changing the
data structure to be protected can make it cheaper to do so. The
scaling of the current prototype is limited by the fraction of the
compilation we parallelize as well as the granularity.
Going forward the most useful things are a) reducing the amount of
state that ends up being shared when we paralellize, b) increase
the fraction of the compilation we paralellize by tackling
RTL optimizations and the early GIMPLE pipeline
The prototype showed that paralellization is beneficial and that it
can be done with a reasonable amount of work.
Richard Biener <firstname.lastname@example.org>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 247165 (AG München)