search for: refscc

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

...iz.com/ or I have > put an > > image at http://reviews.llvm.org/F2073104) > > > > If we do not consider the ref graph, then it is possible for SCC {S,T} > to be > > I'm not sure why you wouldn't consider the ref graph? I think the > general idea is to visit RefSCCs in bottom up order, and when visiting > a RefSCC, visiting the SCC's inside the RefSCC in bottom up order. > > So in your example, given the edges you've shown, we will visit {X,Y} > before visiting {S,T}. > > > A more complicated case is when SCC {S,T} and SCC {X,Y} b...

...gt;> > >>>>> > If we do not consider the ref graph, then it is possible for SCC >>>>> {S,T} to be >>>>> >>>>> I'm not sure why you wouldn't consider the ref graph? I think the >>>>> general idea is to visit RefSCCs in bottom up order, and when visiting >>>>> a RefSCC, visiting the SCC's inside the RefSCC in bottom up order. >>>>> >>>>> So in your example, given the edges you've shown, we will visit {X,Y} >>>>> before visiting {S,T}. >>...

...http://reviews.llvm.org/F2073104) >>> > >>> > If we do not consider the ref graph, then it is possible for SCC {S,T} >>> to be >>> >>> I'm not sure why you wouldn't consider the ref graph? I think the >>> general idea is to visit RefSCCs in bottom up order, and when visiting >>> a RefSCC, visiting the SCC's inside the RefSCC in bottom up order. >>> >>> So in your example, given the edges you've shown, we will visit {X,Y} >>> before visiting {S,T}. >>> >>> > A more co...

Sent from my Verizon Wireless 4G LTE DROID On Jun 8, 2016 1:58 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: > > >> On Jun 8, 2016, at 9:32 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> ________________________________ >>> >>>

...; > If we do not consider the ref graph, then it is possible for SCC >>>>>>> {S,T} to be >>>>>>> >>>>>>> I'm not sure why you wouldn't consider the ref graph? I think the >>>>>>> general idea is to visit RefSCCs in bottom up order, and when >>>>>>> visiting >>>>>>> a RefSCC, visiting the SCC's inside the RefSCC in bottom up order. >>>>>>> >>>>>>> So in your example, given the edges you've shown, we will visit {X,Y}...

On Tue, Jun 14, 2016 at 11:29 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Thu, Jun 9, 2016 at 3:26 AM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Wed, Jun 8, 2016 at 8:14 PM, Xinliang David Li <davidxl at google.com> >> wrote: >> >>> >>> >>> On Wed, Jun 8, 2016 at 4:38 PM, Sean

...llvm-dev wrote: > > Chandler/All, > > We've just started testing the new pass manager this week and we ran > into a 548x slowdown (i.e., 6.28s to 3443.83s) for one of the files > from SPEC2017/blender.  The issue arises only in debug builds due to > the numerous calls to RefSCC::verify() and SCC::verify() in the > LazyCallGraph implementation.  Would it make sense to start > predicating these calls with the EXPENSIVE_CHECKS macro, rather than > NDEBUG? > >  Chad > > > On 10/18/2017 2:50 AM, Chandler Carruth via llvm-dev wrote: >> Greetings...

...ely, I understand the coro-split pass to be > doing exactly those things. > > As a result, if I attempt to mimic the coro-split pass's logic by > inserting functions into the call graph using 'LazyCallGraph::get', > and then adding call edges with > 'LazyCallGraph::RefSCC::insertTrivialRefEdge' and > 'LazyCallGraph::RefSCC::switchInternalEdgeToCall', I'm met with an > assertion: llvm/lib/Analysis/CGSCCPassManager.cpp:463: [...]: > Assertion `E && "No function transformations should introduce *new* " > "call edges! A...

On Sun, Jun 19, 2016 at 12:01 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi David, > > Xinliang David Li wrote: > >> I believe it is primarily used for ordering the visitation of > CallSCC's (i.e. SCC's in the "call graph"). > > This is what it can do -- but what benefit does it provide? > > One benefit is that once you

I have hit a fairly isolated practical issue deploying the new PM, but it does point to a latent theoretical issues as well. I see various ways to address it, but want feedback from others before moving forward. The issue is that we can introduce out-of-thin-air calls to known library functions (`SimplifyLibCalls`, etc). These can be introduced in function passes (`InstCombine` in particular) and

Greetings everyone! The new pass manager is getting extremely close to the point where I'm not aware of any significant outstanding work needed, and I'd like to see what else would be needed to enable it by default. Here are the current functionality I'm aware of outstanding: 1) Does not do non-trivial loop unswitching. Majority of this is in https://reviews.llvm.org/D34200 but will

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