search for: scc's

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

...sanjoy at playingwithpointers.com > wrote: > Hi Sean, > > On Thu, Jun 16, 2016 at 4:48 AM, Sean Silva via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > One question is what invariants we want to provide for the visitation. > > > > For example, should a CGSCC pass be able to assume that all "child" SCC's > > (SCC's it can reach via direct calls emanating from the SCC being > visited) > > have already been visited? Currently I don't think it can, and IIRC from > the > > discussion at the social this is one th...

...gt; Hi Sean, >>> >>> On Thu, Jun 16, 2016 at 4:48 AM, Sean Silva via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> > One question is what invariants we want to provide for the visitation. >>> > >>> > For example, should a CGSCC pass be able to assume that all "child" >>> SCC's >>> > (SCC's it can reach via direct calls emanating from the SCC being >>> visited) >>> > have already been visited? Currently I don't think it can, and IIRC >>> from the >...

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

..., 2016 at 4:48 AM, Sean Silva via llvm-dev >>>>> <llvm-dev at lists.llvm.org> wrote: >>>>> > One question is what invariants we want to provide for the >>>>> visitation. >>>>> > >>>>> > For example, should a CGSCC pass be able to assume that all "child" >>>>> SCC's >>>>> > (SCC's it can reach via direct calls emanating from the SCC being >>>>> visited) >>>>> > have already been visited? Currently I don't think it can, and...

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

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

On Wed, Jun 8, 2016 at 12:36 PM, Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > Does it make sense to change RefSCCs to hold a list of > RefSCC-DAG-Roots that were split out of it because of edge deletion? > Then one way to phrase the inliner/function pass iteration would be > (assuming I understand the issues): > > Stack.push(RefSCC_Leaves); > while (!Stack.empty()) { > RefSCC = Sta...

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

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

...unctions, passes, etc. as a compilation unit is being optimized. The developer can then use these numbers to selectively disable parts of the optimization without otherwise altering the behavior of the compiler. In keeping with the current LLVM pass manager structure, I am handling module passes, SCC passes and function passes separately. I propose handling loop, region and basic block passes as if they were function passes. (I think what this means will become clear below.) Because the handling of function passes illustrates well all of the steps involved in using the feature I am proposing...

...asses, etc. as a compilation unit is being optimized. The developer can then use these numbers to selectively disable parts of the optimization without otherwise altering the behavior of the compiler. > > In keeping with the current LLVM pass manager structure, I am handling module passes, SCC passes and function passes separately. I propose handling loop, region and basic block passes as if they were function passes. (I think what this means will become clear below.) Because the handling of function passes illustrates well all of the steps involved in using the feature I am proposing...

...tc. as a compilation unit is being optimized. The developer can then use these numbers to selectively disable parts of the optimization without otherwise altering the behavior of the compiler. >> >> In keeping with the current LLVM pass manager structure, I am handling module passes, SCC passes and function passes separately. I propose handling loop, region and basic block passes as if they were function passes. (I think what this means will become clear below.) Because the handling of function passes illustrates well all of the steps involved in using the feature I am proposing...

...unctions, passes, etc. as a compilation unit is being optimized. The developer can then use these numbers to selectively disable parts of the optimization without otherwise altering the behavior of the compiler. In keeping with the current LLVM pass manager structure, I am handling module passes, SCC passes and function passes separately. I propose handling loop, region and basic block passes as if they were function passes. (I think what this means will become clear below.) Because the handling of function passes illustrates well all of the steps involved in using the feature I am proposing...

...ev >>>>>>> <llvm-dev at lists.llvm.org> wrote: >>>>>>> > One question is what invariants we want to provide for the >>>>>>> visitation. >>>>>>> > >>>>>>> > For example, should a CGSCC pass be able to assume that all >>>>>>> "child" SCC's >>>>>>> > (SCC's it can reach via direct calls emanating from the SCC being >>>>>>> visited) >>>>>>> > have already been visited? Current...

...asses, etc. as a compilation unit is being optimized. The developer can then use these numbers to selectively disable parts of the optimization without otherwise altering the behavior of the compiler. > > In keeping with the current LLVM pass manager structure, I am handling module passes, SCC passes and function passes separately. I propose handling loop, region and basic block passes as if they were function passes. (I think what this means will become clear below.) Because the handling of function passes illustrates well all of the steps involved in using the feature I am proposing...

...compilation unit is being optimized. The developer can then use these numbers to selectively disable parts of the optimization without otherwise altering the behavior of the compiler. >>> >>> In keeping with the current LLVM pass manager structure, I am handling module passes, SCC passes and function passes separately. I propose handling loop, region and basic block passes as if they were function passes. (I think what this means will become clear below.) Because the handling of function passes illustrates well all of the steps involved in using the feature I am proposing...

Test Cases: (attached) Iteration code: (...) typedef TarjanSCC_iterator<CallGraph*> MyTarjan; CallGraph& callGraph = getAnalysis<CallGraph>(); MyTarjan iter = tarj_begin(&callGraph); MyTarjan end = tarj_end(&callGraph); while(iter!=end) iter++; (...) if you take the time to print out the function each non-looping node iter t...

...as a compilation unit is being optimized. > The developer can then use these numbers to selectively disable parts of the > optimization without otherwise altering the behavior of the compiler. > > In keeping with the current LLVM pass manager structure, I am handling > module passes, SCC passes and function passes separately. I propose > handling loop, region and basic block passes as if they were function > passes. (I think what this means will become clear below.) Because the > handling of function passes illustrates well all of the steps involved in > using the fe...