similar to: [LLVMdev] loop passes vs call graph

Hi, > I'm looking at bug 3367. > > If I run: > > $ opt b.bc -inline -loop-rotate -loop-unswitch -debug-pass=Executions > > ... it eventually crashes in the inliner, because the call graph isn't > up to date. (NB if you want to reproduce this you'll have to apply my > patch from bug 3367 first.) > > The reason the call graph isn't up to date is

On Feb 13, 2009, at 5:39 AM, Duncan Sands wrote: > Hi, > >> I'm looking at bug 3367. >> >> If I run: >> >> $ opt b.bc -inline -loop-rotate -loop-unswitch -debug-pass=Executions >> >> ... it eventually crashes in the inliner, because the call graph >> isn't >> up to date. (NB if you want to reproduce this you'll have to

On Nov 29, 2010, at 1:17 AM, Duncan Sands wrote: > Hi David, > >> Interesting -- LLVM does perform on the fly cleanups during inlining >> transformation -- this will make summary update precise. One thing I notice from >> the debug pass dump is that the 'deduce function attribute' pass happens before >> the clean up -- Is it intended? > > you are

On Nov 29, 2010, at 5:01 PM, Devang Patel wrote: > > On Nov 29, 2010, at 1:17 AM, Duncan Sands wrote: > >> Hi David, >> >>> Interesting -- LLVM does perform on the fly cleanups during inlining >>> transformation -- this will make summary update precise. One thing I notice from >>> the debug pass dump is that the 'deduce function

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 Silva <chisophugis at gmail.com> wrote: > >> >> >> 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

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

Hi David, > Interesting -- LLVM does perform on the fly cleanups during inlining > transformation -- this will make summary update precise. One thing I notice from > the debug pass dump is that the 'deduce function attribute' pass happens before > the clean up -- Is it intended? you are correct. This is due to a limitation of the pass manager: it would clearly be better to

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 traverses, it never reaches main...

On Mon, Nov 29, 2010 at 1:17 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi David, > > > Interesting -- LLVM does perform on the fly cleanups during inlining > > transformation -- this will make summary update precise. One thing I > notice from > > the debug pass dump is that the 'deduce function attribute' pass happens > before > > the clean

On Wed, Nov 24, 2010 at 12:37 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Xinliang David Li wrote: > >> Hi, I browsed the LLVM inliner implementation, and it seems there is >> room for improvement. (I have not read it too carefully, so correct me >> if what I observed is wrong). >> >> First the good side of the inliner -- the function level summary

Functions in LLVM IR have a function_entry_count metadata that is attached in PGO compilation. By using the entry count together with the block frequency info, the compiler computes the profile count of call instructions based on which the hotness/coldness of callsites can be determined. Experiments have shown that using a higher threshold for hot callsites results in improved runtime performance

I am working on a transform that uses an scc_iterator on a program's CallGraph. However, I am running into a problem in which not all callees are being processed before callers, leading me to believe there might be a bug. In particular, this is happening in a case where a callee is a function pointer. I ran bugpoint and have included the bugpoint-reduced-simplified.ll below. If

Thanks, I've been through the documentation, and if I visit main, i think everything will turn out correctly... Printing out the Call graph reveals that main is calling this external node i think you are making reference to. Could this be the problem? Dave On Fri, 6 Dec 2002, Chris Lattner wrote: > > if you take the time to print out the function each non-looping node iter >

On Nov 29, 2010, at 5:15 PM, Chris Lattner wrote: > > On Nov 29, 2010, at 5:01 PM, Devang Patel wrote: > >> >> On Nov 29, 2010, at 1:17 AM, Duncan Sands wrote: >> >>> Hi David, >>> >>>> Interesting -- LLVM does perform on the fly cleanups during inlining >>>> transformation -- this will make summary update precise. One

On Monday 15 March 2010 13:45:14 David Greene wrote: > On Sunday 14 March 2010 18:32:35 Chris Lattner wrote: > > This is much better than the first iteration but still has many issues. I believe I've addressed all your points with this patch except I didn't use StringRef. It doesn't appear to be useful since createPrinterPass will be sent a const std::string & and will

Hi, I'm trying to inline function defined in another bitcode module via bitcode modification. I'm linking multiple bitcode modules, setting inline related attributes, applying -always-inline pass, but then debug info error occurs. It seems debug info metadata isn't properly updated on inlining. How can I fix it? I'm using LLVM 3.8.1 on OS X (On below example target is Android but

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

On Sun, 3 Dec 2006, Ryan M. Lefever wrote: > I am working on a transform that uses an scc_iterator on a program's > CallGraph. However, I am running into a problem in which not all > callees are being processed before callers, leading me to believe there > might be a bug. In particular, this is happening in a case where a > callee is a function pointer. I ran bugpoint and

Hey all, I'm working on adding function attribute propagation to function summaries in the ThinLTO index, and have run into some trouble with ensuring bottom-up traversal when finding the SCCs in the call graph. I'm basing my implementation for the GraphTraits for the ModuleSummaryIndex off the GraphTraits<CallGraph *> implementation (

I printed the call graph as you suggested. The bugpoint bytecode that I sent below prints the following call graph: Indirect call node / | | \ / | | \ V | V V execute | prog_char clear_func | | V V push_constant | V Node0x8d7b370 i.e., Indirect call node -> execute