Re: Multi-Threading GCC Compiler Internal Data

[Richard Biener <rguenther@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

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.
> >
> 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.

Richard.