similar to: Let CallGraphSCCPass Use Function-Level Analysis

Hi Mikhail, As Brian noted, stuff like this works better in the new pass manager. Even in the old pass manager I thought it should work though. Did you initialize the pass, via `INITIALIZE_PASS_DEPENDENCY(PostDominatorTreeWrapperPass)`? Did you require it, via ` AU.addRequired<PostDominatorTreeWrapperPass>();`? Btw. May I ask what you are planning to do? Cheers, Johannes On 01/07,

Hi Chandler, This is a high-level review of the new WIP `PassManager` infrastructure. For those that haven't dug into Chandler's commits, here's a very high-level overview (assuming IIUC): - The driver supports simple declarative syntax for specifying passes to run. E.g., `module(a,b,function(c,d),e)` runs module passes `a` and `b`, then function passes `c` and `d` for

Hi everyone, I write a new FunctionPass which wants to use pass PostDominatorTree, so I implement the next function: void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<PostDominatorTree>(); AU.setPreservesAll(); } Then I get PDT through the next statement: PostDominatorTree *PDT = &getAnalysis<PostDominatorTree>(); My code can be successfully

Hello all, It's been a month since my previous email on the topic, and since then I've done some initial work on porting the coroutines passes to the new pass manager. In total there are 6 patches -- that's a lot to review, so allow me to introduce the changes being made in each of them. # What's finished In these first 6 patches, I focused on lowering coroutine intrinsics

Hi, You need to initialize your pass with: INITIALIZE_PASS_BEGIN(YourPass, "your-pass", "Your Pass", /*cfgonly=*/false, /*analysis=*/false) INITIALIZE_PASS_DEPENDENCY(PostDominatorTreeWrapperPass) INITIALIZE_PASS_END(YourPass, "your-pass", "Your Pass", /*cfgonly=*/false, /*analysis=*/false) So as to both register your pass, and have

> On Jun 8, 2016, at 9:32 AM, Hal Finkel via llvm-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,

Hi folks, For the past month I’ve been working on improving the DominatorTree and PostDominatorTree in LLVM. The RFC that explains the motivations and plans can be found here: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114045.html . Here’s a short summary of what changed upstream since posting it: - We switched from the Simple Lengauer-Tarjan algorithm for computing dominators

Wenbin Zhang wrote: > I'll try the trunk, as well as check my code again. If indeed it's not > fixed, I'll try to post a triggering case here. > Thanks for the advice~ > Did you run the -mergereturn pass (it might also be called UnifyExitNodes in the source code)? This is the pass that ensures that each function has exactly one basic block that returns control to the

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

Hi Philip, Thanks for the response. Under llvm-5.0.2 and llvm-6.0.1 in Debug mode, the crash hit at the same assertion: /usr/local/include/llvm/IR/PassManager.h:689: typename PassT::Result& llvm::AnalysisManager<IRUnitT, ExtraArgTs>::getResult(IRUnitT&, ExtraArgTs ...) [with PassT = llvm::InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::Loop,

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

On Wed, Jun 8, 2016 at 9:39 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Wed, Jun 8, 2016 at 4:19 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

On 08/05/2010 06:46 AM, Wenbin Zhang wrote: > Hi all, > I'm using postDominatorTree to do some program analysis. My code works > well for small tests, but when I run it on real applications, the > following error occurs: > /Inorder PostDominator Tree: DFSNumbers invalid: 0 slow queries. > [1] <<exit node>> {0,21} > [2] %bb1 {1,2} > [2] %bb {3,4} > [2]

Hello, I'm trying to improve SimpleInliner to use information given by __builtin_expect instruction (It would be better to not to inline if a call instruction is unlikely to be executed). The problem here is that it is not possible to compute control dependency relationship between the annotated branch instruction and callsites using PostDominatorTree, because PostDominatorTree is a function

I have written a module pass. When I use the debug pass structure option, the name of my module pass is printed but then I get "Unnamed pass" when the FunctionPassManagerImpl *FPP calls dumpPassStructure (in PassManager.cpp). Is this the expected behavior, or should I be concerned that there is an error in my approach? Thanks, Scott

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: >> >> >> ________________________________ >>> >>>

Hi! I wonder if llvm::APFloat::toString() can be const since it should not modify the APFloat. -Jochen

Hi folks, Per the documentation[0], whenever an LLVM pass doesn't modify the IR it's run on, it should return `false`--it's okay to return `true` if no change happen, just less optimal. In the New PM area, this is generally translated into a `PreservedAnalyses::all()`. https://reviews.llvm.org/D80916 provides an `EXPENSIVE_CHECK` that computes a hash of the IR before and after the

On Thu, Jun 16, 2016 at 10:47 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Jun 16, 2016 at 9:53 PM, Xinliang David Li <davidxl at google.com> > wrote: > >> >> >> On Thu, Jun 16, 2016 at 11:12 AM, Sanjoy Das < >> sanjoy at playingwithpointers.com> wrote: >> >>> Hi Sean, >>> >>> On Thu, Jun

On Wed, Jun 8, 2016 at 12:31 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Wed, Jun 8, 2016 at 4:19 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