This is the mail archive of the
mailing list for the GCC project.
Re: Multi-Threading GCC Compiler Internal Data
On Tue, 17 Sep 2019, Nicholas Krause wrote:
> On 9/17/19 2:37 AM, Richard Biener wrote:
> > 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
> >> would
> >> allow us to figure out much better what algorthims or data structures to
> >> choose
> >> 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.
> Sorry I think your misunderstanding me. I was asking whats the best way to
> write a tool to expose twhere and how the shared state is using being used.
Such tool would need to solve the halting problem so it cannot exist.