similar to: [LLVMdev] how to delete an invalidated call graph

It is ModulePass with AnalysisUsage of CallGraph Yours sincerely, Kadysev Mikhail 22.04.2012, в 5:20, Nick Lewycky написал(а): > Михаил wrote: >> Thanks, but I replaceAllUsesWith() - works well, but I still get bug in >> eraseFromParent(): >> >> While deleting: i32 (%class.B*, i32)* %_ZN1B1xEi >> An asserting value handle still pointed to this value! >>

Михаил wrote: > It is ModulePass with AnalysisUsage of CallGraph Ah, then you'll need to update the CallGraph first. Use "CG.removeFunctionFromModule(F);" before deleting it. Nick > Yours sincerely, > Kadysev Mikhail > > 22.04.2012, в 5:20, Nick Lewycky написал(а): > >> Михаил wrote: >>> Thanks, but I replaceAllUsesWith() - works well, but I still

Dear everyone, I want to traverse call graph, but I have some trouble . In my pass MyPass which need to traverse call graph, I firstly added the CallGraph analysis to the pass requirements by *AU.addRequired<CallGraph>();* My pass MyPass then will be added to a pass manager by *manager.add(new MyPass());* and then I want to traverse the call graph such as: CallGraph CG =

I recall having a similar problem while coding my own special-purpose "opt". My guess: try adding the following lines before your pass is inserted into the PassManager: PassRegistry &Registry = *PassRegistry::getPassRegistry(); initializeIPA(Registry); You might require other library initializations. Have a look at the "opt" source code. On 02/12/13 10:36,

This thread kinda died. I'd like to revive it. The new PM stuff is making excellent progress, and this is actually one of the last things to clean up. On Mon, Aug 8, 2016 at 1:10 AM Sean Silva <chisophugis at gmail.com> wrote: > Thoughts? For the moment I have put in a workaround (r274457) that makes > jump-threading invalidate LVI. > > > Is everybody happy with this

Hello, On the following code, // #include <stdio.h> void f2(); int main(){ f2(); return 0; } void f2(){ printf("f2()\n"); } // I have obtained the .bc file and run opt -print-callgraph finename.bc. For the main function, the output of the above command is: Call graph node for function: 'main' Calls external node However, the function called by

Hi We have applied the routing patches from http://www.ssi.bg/%7Eja/#routes. To 2.6.15 this seems to have broken our output natting. Has anyone else experienced this or any advice on how to fix. Is this working on the newer kernel i.e. 2.6.19 ? Any help would be appreciated. -- Tim Haak email: tim@haak.co.uk cel: 0837787100 First love is only a little foolishness and a lot of curiosity,

Hi all, I had a look at the interprocedural optimizer. In my opinion the routine 'GlobalOpt::ProcessInternalGlobal' is a little bit to conservative. It removes global variables if the only routine using this variable is main. Typically this condition is valid only for very few global variables. Here is a code snippet containing the test before the transformation: file:

I am finding some weird behavior in the CallGraph, and am not sure what am I doing wrong. When trying to traverse nodes in the CallGraph I get stuck in nodes representing external functions. Take the following code: ----- #include <stdio.h> int main() { printf( "Hello World!\n" ); } ----- If I try to traverse the CallGraph using the following code: ----- CallGraph CG

Hi you basically need to find a cycles in the call graph. Do do this just search google for a graph algorithm, then make it for your problem. See http://en.wikipedia.org/wiki/Cycle_detection. Jeff Kunkel On Tue, Nov 2, 2010 at 4:27 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Trevor, > > > Converting my ModulePass to a CallGraphSCCPass doesn't seem feasible, so >

Hello, I want an instance of CallGraph in my pass. By looking at -dot-callgraph source, I've tried something like this: CallGraphWrapperPass *CGWP = new CallGraphWrapperPass(); PM.add(CGWP); CallGraph *CG = &CGWP->getCallGraph(); PM.add(new MyPass(CG)); I get the following error: /home/riyad/installs/llvm-3.7.0/include/llvm/PassSupport.h:95:38: error: no matching constructor for

On Nov 2, 2010, at 12:53 PM, Jeff Kunkel wrote: > Also, could you write this in a separate pass, and obtain the > results from getAnalysis()? I think others would find it useful to > discover if a Function may be called recursively. I've modified the code so that it correctly identifies both direct and indirect recursion. I'm now trying to package it up as a patch for the

Also, could you write this in a separate pass, and obtain the results from getAnalysis()? I think others would find it useful to discover if a Function may be called recursively. -Jeff Kunkel On Tue, Nov 2, 2010 at 2:38 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > Hi you basically need to find a cycles in the call graph. Do do this just > search google for a graph algorithm, then

Hi All, We have this piece of code in our system , where we are iteratively remove functions that were unreachable in the cfg. In llvm-2.6 func->eraseFromParent() worked but now we want to move to llvm-2.7 we get a the following assert. An asserting value handle still pointed to this value! UNREACHABLE executed at llvm-2.7/lib/VMCore/Value.cpp: 522! CODE

On 5/10/09, Török Edwin <edwintorok at gmail.com> wrote: > On 2009-05-10 20:11, Nick Johnson wrote: > > Hello, > > > > I'm writing a Function Pass. This function pass needs access to the > > CallGraph and CallGraph SCCs. Is there any way I can get CallGraph > > information without changing my pass to a CallGraphSCCPass ? > > > Does

Hello, I'm writing a Function Pass. This function pass needs access to the CallGraph and CallGraph SCCs. Is there any way I can get CallGraph information without changing my pass to a CallGraphSCCPass ? Thanks, -- Nick Johnson

Hi, I have been working on implementing new analysis for a LLVM module. For that, I need that Call Graph of the module. Inside the CallGraph file, the constructor has been declared "protected" hence I can't define its instance and thus use the CallGraph for further analysis. So, what are the ways of building and using Call Graph of a module. Do I need to make my new analysis as

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

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 that -loop-unswitch has changed a function and not updated

Hello: We are working with LLVM-3.1 and we have a problem.This is the code we have executed: virtual void getAnalysisUsage( llvm::AnalysisUsage & info ) const { info.addRequired<CallGraph>(); ... } ... virtual bool runOnModule( Module & M ) { ... CallGraph &CG = this->getAnalysis<CallGraph>(); CallGraphNode *cgn; unsigned nref;