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.
