search for: cgscc

...lees before visiting the callers). > Not necessarily. Due to lost edges (from caller to indirect callees), a callee node may be visited later. The analysis will just have to punt when a special edge to 'external' node is seen. David > > -Hal > > Consider the pipeline `cgscc(function(...simplifications that can > devirtualize...),foo-cgscc-pass)`. A possible visitation is as follows: > > 1. Visit SCC {S,T} and run `function(...simplifications that can > devirtualize...)`. This reveals the call edge T->Y. > 2. We continue visiting SCC {S,T} and run foo...

Hi Chandler, Philip, Mehdi, (and llvm-dev,) (this is partially a summary of some discussions that happened at the last LLVM bay area social, and partially a discussion about the direction of the CGSCC pass manager) A the last LLVM social we discussed the progress on the CGSCC pass manager. It seems like Chandler has a CGSCC pass manager working, but it is still unresolved exactly which semantics we want (more about this below) that are reasonably implementable. AFAICT, there has been no publi...

----- Original Message ----- > From: "Sean Silva via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, June 8, 2016 6:19:03 AM > Subject: [llvm-dev] Intended behavior of CGSCC pass manager. > Hi Chandler, Philip, Mehdi, (and llvm-dev,) > (this is partially a summary of some discussions that happened at the > last LLVM bay area social, and partially a discussion about the > direction of the CGSCC pass manager) > A the last LLVM social we discussed the pr...

...wrote: >>> >>>> Hi Chandler, Philip, Mehdi, (and llvm-dev,) >>>> >>>> (this is partially a summary of some discussions that happened at the >>>> last LLVM bay area social, and partially a discussion about the direction >>>> of the CGSCC pass manager) >>>> >>>> >>>> A the last LLVM social we discussed the progress on the CGSCC pass >>>> manager. It seems like Chandler has a CGSCC pass manager working, but it is >>>> still unresolved exactly which semantics we want (more ab...

...AM, Sean Silva <chisophugis at gmail.com> wrote: > >> Hi Chandler, Philip, Mehdi, (and llvm-dev,) >> >> (this is partially a summary of some discussions that happened at the >> last LLVM bay area social, and partially a discussion about the direction >> of the CGSCC pass manager) >> >> >> A the last LLVM social we discussed the progress on the CGSCC pass >> manager. It seems like Chandler has a CGSCC pass manager working, but it is >> still unresolved exactly which semantics we want (more about this below) >> that are reason...

...vm-dev <llvm-dev at lists.llvm.org> wrote: > > > From: "Sean Silva via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, June 8, 2016 6:19:03 AM > Subject: [llvm-dev] Intended behavior of CGSCC pass manager. > > Hi Chandler, Philip, Mehdi, (and llvm-dev,) > > (this is partially a summary of some discussions that happened at the last LLVM bay area social, and partially a discussion about the direction of the CGSCC pass manager) > > > A the last LLVM social we discu...

...; <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> >>> To: "llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> >>> Sent: Wednesday, June 8, 2016 6:19:03 AM >>> Subject: [llvm-dev] Intended behavior of CGSCC pass manager. >>> >>> Hi Chandler, Philip, Mehdi, (and llvm-dev,) >>> >>> (this is partially a summary of some discussions that happened at the last LLVM bay area social, and partially a discussion about the direction of the CGSCC pass manager) >>> >&...

...> Hi Chandler, Philip, Mehdi, (and llvm-dev,) >>>>>> >>>>>> (this is partially a summary of some discussions that happened at the >>>>>> last LLVM bay area social, and partially a discussion about the direction >>>>>> of the CGSCC pass manager) >>>>>> >>>>>> >>>>>> A the last LLVM social we discussed the progress on the CGSCC pass >>>>>> manager. It seems like Chandler has a CGSCC pass manager working, but it is >>>>>> still unresolved...

...t;>>> From: "Sean Silva via llvm-dev" <llvm-dev at lists.llvm.org> > >>>> To: "llvm-dev" <llvm-dev at lists.llvm.org> > >>>> Sent: Wednesday, June 8, 2016 6:19:03 AM > >>>> Subject: [llvm-dev] Intended behavior of CGSCC pass manager. > >>>> > >>>> Hi Chandler, Philip, Mehdi, (and llvm-dev,) > >>>> > >>>> (this is partially a summary of some discussions that happened at the > >>>> last LLVM bay area social, and partially a discussion about t...

...AM, Sean Silva <chisophugis at gmail.com> wrote: > >> Hi Chandler, Philip, Mehdi, (and llvm-dev,) >> >> (this is partially a summary of some discussions that happened at the >> last LLVM bay area social, and partially a discussion about the direction >> of the CGSCC pass manager) >> >> >> A the last LLVM social we discussed the progress on the CGSCC pass >> manager. It seems like Chandler has a CGSCC pass manager working, but it is >> still unresolved exactly which semantics we want (more about this below) >> that are reason...

...intervened, but he's still got a great point, so I wanted to get it out there with one day to spare before he nagged me again. =D I'll keep it very brief and high level. If folks have questions about anything, happy to dig into it. - The core framework is there. It works, and we even have CGSCC passes using both Module and Function analyses with caching and everything. Yay! We also have initial loop pass infrastructure thanks to Justin! Yay! - The biggest missing piece of infrastructure IMO is communicating invalidation information between two parts of the pass manager itself when they a...

...phugis at gmail.com> wrote: >> >>> Hi Chandler, Philip, Mehdi, (and llvm-dev,) >>> >>> (this is partially a summary of some discussions that happened at the >>> last LLVM bay area social, and partially a discussion about the direction >>> of the CGSCC pass manager) >>> >>> >>> A the last LLVM social we discussed the progress on the CGSCC pass >>> manager. It seems like Chandler has a CGSCC pass manager working, but it is >>> still unresolved exactly which semantics we want (more about this below) >...

...I wanted to get it out >> there with one day to spare before he nagged me again. =D >> >> I'll keep it very brief and high level. If folks have questions about >> anything, happy to dig into it. >> >> - The core framework is there. It works, and we even have CGSCC passes >> using both Module and Function analyses with caching and everything. Yay! >> We also have initial loop pass infrastructure thanks to Justin! Yay! >> >> - The biggest missing piece of infrastructure IMO is communicating >> invalidation information between two...

...' gets cloned as NewBB in 'foo'. NewBB's block frequency > can be incrementally computed from OldBB's block frequency, entry block > frequency of 'bar' and the frequency of the block containing the 'foo' -> > 'bar' callsite. Even when the new CGSCC level BFI analysis is in place, > this incremental update is useful to minimize computation. > > Invalidation: Once inlining is completed in an SCC (at the end of > runOnSCC), the entries for functions in that SCC are invalidated since > other passes run by the CGSCC pass manager (i...

On Tue, Jul 16, 2013 at 1:18 PM, Xinliang David Li <xinliangli at gmail.com>wrote: > Ignoring FE time which can be fully parallelized and assuming 10% > compile time is spent in serial module passes, 25% time is spent in > CGSCC pass, the maximum speed up that can be gained by using function > level parallelism is less than 3x. Even adding support for parallel > compilation for leaves of CG in CGSCC pass won't help too much -- the > percentage of leaf functions is < 30% in large apps I have seen. > Can...

...e > solution that piggybacks on the PGO mechanism and Just Works. > > If that is correct then this makes perfect sense to me. > Yes, that is the proposal. > > It could be argued that we ought to refactor things so that the raw PGO > metadata is only ever accessed via a wrapper CGSCC analysis that falls back > to interprocedural analysis (i.e. static profile heuristics) when the entry > count metadata is missing, just like BPI does with static intraprocedural > analysis and branch weight metadata. However, we probably don't want to do > that while folks are stil...

...gt; On Tue, Jul 16, 2013 at 1:18 PM, Xinliang David Li <xinliangli at gmail.com > > > > wrote: > >> > >> Ignoring FE time which can be fully parallelized and assuming 10% > >> compile time is spent in serial module passes, 25% time is spent in > >> CGSCC pass, the maximum speed up that can be gained by using function > >> level parallelism is less than 3x. Even adding support for parallel > >> compilation for leaves of CG in CGSCC pass won't help too much -- the > >> percentage of leaf functions is < 30% in large...

...loned as NewBB in 'foo'. NewBB's block frequency >> can be incrementally computed from OldBB's block frequency, entry block >> frequency of 'bar' and the frequency of the block containing the 'foo' -> >> 'bar' callsite. Even when the new CGSCC level BFI analysis is in place, this >> incremental update is useful to minimize computation. >> >> Invalidation: Once inlining is completed in an SCC (at the end of >> runOnSCC), the entries for functions in that SCC are invalidated since other >> passes run by the C...

...for C++ code that LLVM does. We can't sink all of the loop passes out of the iterative pass model either, because deleting loops, simplifying them, etc. all directly feed the iterative simplification needed by GVN and the inliner. We need a *second* loop pass that happens after the iterative CGSCC walk which does the further optimizations such as (potentially indvars, ) the vectorizers, LSR, lower-switch, CGP, CG. I think we actually want most of the post CGSCC module passes to run after the vectorizers and before LSR to fold away constants and globals that look different after vectorization...

...ing" of passes is really important > for C++ optimization (among other things) where optimizing a function can > dramatically shrink it (due to abstraction penalties being removed)… which > then makes it a much strongly inline candidate. > Yes, this is the intended behavior of the CGSCC pass, and in an optimized build there is a pass manager extension hook for putting a function pass into this process. However, the -O1 (and higher) pass managers expose the OptimizeLast extension point after several module passes, and thus they run in their own function pass manager. This is desir...