similar to: [LLVMdev] InstCount

Patrick Simmons wrote: > Hello, > > I'm trying to print the instruction count of a bytecode file using the > 2.4 release of LLVM. I found llvm-2.4/lib/Analysis/Instcount.cpp but > I'm not sure what to do with it. I also looked at llvm-bcanalyzer. The > documentation says this command is supposed to print the instruction > count in the summary, but it doesn't

On Mar 30, 2009, at 12:08 PM, John Criswell wrote: > Dear All, > > Does llvm-bcanalyzer still print the number of instructions in a > bitcode > file, or has that functionality been removed? Try the "opt -instcount -stats" option, -Chris

Dear All, Does llvm-bcanalyzer still print the number of instructions in a bitcode file, or has that functionality been removed? -- John T.

Great! For the hotness, try creating a small test case with a very hot loop that iterates many times. Let me know if you are still having trouble. While the llvm-dis serialization is being discussed, I suppose at the very least this can go in with the rest of the existing YAML summary dumping and get emitted from llvm-lto2 using the patch Peter attached. Peter - do you want to add that to

Thanks a lot Chris. Regarding basic block size I wish to calculate both: - The number of bytecode bytes - The number of machine code bytes for some target? TS Chris Lattner <sabre at nondot.org> wrote: On Thu, 7 Apr 2005, Tanu Sharma wrote: > Thanks for the reply, > > Actually I m aiming towards determining two values: > > - number of basic blocks in a program For

On Wed, Jun 7, 2017 at 8:58 AM, Charles Saternos <charles.saternos at gmail.com > wrote: > Alright, now it outputs YAML in the following format: > > --- > NamedGlobalValueMap: > X: > - Kind: GlobalVar > Linkage: ExternalLinkage > NotEligibleToImport: false > Live: false > a: > - Kind:

Hi, I am new to llvm and have read all the documents and managed to get the llvm tool working on linux without much problem. I am trying to generate some static analysis information about my program using llvm virtual machine architecture. the file is really simple hello world program with a small loop which increments a variable until a particular iteration. main() { int a,b,c; a=0; b=0; c=1;

There’s a few passes in LLVM that make heavy use of a big DenseMap, one that potentially gets filled with up to 1 entry for each instruction in the function. EarlyCSE is the best example, but Reassociate and MachineCSE have this to some degree as well (there might be others?). To put it simply: at least in my profile, EarlyCSE spends ~1/5 of its time growing DenseMaps. This is kind of… bad.

> On Mar 15, 2016, at 4:09 PM, Philip Reames <listmail at philipreames.com> wrote: > > > > On 03/15/2016 03:07 PM, via llvm-dev wrote: >> There’s a few passes in LLVM that make heavy use of a big DenseMap, one that potentially gets filled with up to 1 entry for each instruction in the function. EarlyCSE is the best example, but Reassociate and MachineCSE have this to

Here's some stuff that may be useful for your papers n stuph: * Analyze has a pass "-instcount" written by Dinakar, which will tell you things like the number of functions, basic blocks, and instructions are in a program. It will even classify the instructions into different opcodes, if you want to report things like #loads+#stores or something. * Most of the olden

What should we use instead of DenseMap? —escha > On Mar 15, 2016, at 3:30 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > > yes it makes sense. Avoid using DenseMap when the size of the map is expected to be large but can not be pre-determined. > > David > > On Tue, Mar 15, 2016 at 3:07 PM, via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

On Mon, Jul 17, 2017 at 6:11 AM Charles Saternos via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hey @chandlerc and @dblaikie, > > Any updates on this in relation to "[PATCH] D34080: [ThinLTO] Add > dump-summary command to llvm-lto2 tool"? > Sorry you've kind of got stuck in the middle of this - but I'm still hoping to hear/understand the pushback on

> Hi All, > Attached above my InstCount.cpp after modification. I did simple > modification which is the following (The statements between the > ************** ) : > bool InstCount::runOnFunction(Function &F) { > unsigned StartMemInsts = > NumGetElementPtrInst + NumLoadInst + NumStoreInst + NumCallInst + > NumInvokeInst + NumAllocaInst; >

Okay, are C standard library functions typically external in a fully linked LLVM bytecode file? --Patrick Andrew Lenharth wrote: > If the function is external, then DSA won't create a graph for it. > > Andrew > > On Mon, Jul 13, 2009 at 4:54 PM, Patrick Alexander > Simmons<simmon12 at cs.uiuc.edu> wrote: > >> I'm noticing that DSA graphs are not

Thanks for the reply, Actually I m aiming towards determining two values: - number of basic blocks in a program For this I have used Statistic facility provided in llvm and increasing the counter for each basic block for each function.but for some reason , I m getting different number everytime !! Is Statistic is the right way to do it ? - Average basic block size in a program ( in bytes)

2017-06-06 13:38 GMT-07:00 David Blaikie <dblaikie at gmail.com>: > > > On Tue, Jun 6, 2017 at 1:26 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> 2017-06-05 14:27 GMT-07:00 David Blaikie via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> I know there's been a bunch of discussion here already, but I was >>> wondering if

I'm noticing that DSA graphs are not created for library functions like "puts". The bytecode file runs with lli, so I think I did my linking okay. Is this normal, or does it mean I'm somehow not giving the algorithm the complete program information it needs? Thanks, --Patrick

Hi, I'm trying to run the tests in llvm-suite, but I've run into trouble. First, I had the llvm-suite checkout in a directory alongside the llvm compiler checkout, but, when I ran "make" from llvm-suite, it complained about there not being a Makefile two levels above it, so I moved llvm-suite into the "test" subdirectory inside the llvm compiler checkout. I ran

I have completed work merging PARSEC into the LLVM test suite infrastructure? The patch is available at [http://zion.cs.uiuc.edu/~simmon12/parsec.patch]. If there are no objections, would someone please commit this patch to test-suite? Best regards, --Patrick

I read this before posting; however, that article says that the first operand to this instruction must be a pointer type. The type I have is [16 x i8*], not [16 x i8*]*. --Patrick Óscar Fuentes wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.comp.compilers.llvm.devel as well. > > Patrick Simmons <simmon12 at illinois.edu>