search for: bcanalyzer

Chad, Yes it helps, thanks. I have started hacking bitcode-analyzer. ---ajonwa ----- Original Message ----- From: Chad Rosier Sent: 11/05/11 09:07 PM To: ajonwa ajonwa Subject: Re: [LLVMdev] Enable Detailed Output llvm-bcanalyzer ajonwa, It will provide some of the information you're seeking, but not all. Here's a partial dump from one of the bitcode test cases: ./llvm-bcanalyzer ~/llvm/test/Bitcode/spirit-llvm-2.9.ll.bc 2>&1 | less Block ID #12 (FUNCTION_BLOCK): Num Instances: 4370 Total Size: 36964...

Hi, Andreas Neustifter <astifter-llvm at gmx.at> writes: > Maybe you can use the already available "include/llvm/Support/Format.h"? Thanks, that simplifies the patch a lot. See the attached patch. Btw, llvm-bcanalyzer.cpp seems to also use fprintf -- does mixing it with errs() cause problems and should it be converted to use format()? best regards, Timo Lindfors -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-bcanalyzer-format-percentage2.patch Type: text/x-diff Size: 1...

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

Hello, llvm-bcanalyzer told me that the size of the BLOCKINFO_BLOCK of my file is "1.345017e+01" percent of the whole file. This is not very readable. The attached patch prints the percentage without scientific notation so we get something bit more readable: Block ID #0 (BLOCKINFO_BLOCK): Num Instances: 1...

When you do $ llvm-bcanalyzer hello.o | less you won't see anything, because bcanalyzer sends all of it's output to stderr. However, it get's it right when asked for help: $ llvm-bcanalyzer --help | less

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

Hello all, Does anyone know how to make llvm-bcanalyzer produce detailed output i.e. provides additional information on a per-function basis. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111105/8e7fe152/attachment.html>

conversion of llvm-bcanalyzer.cpp compiles, but not runtime tested Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: llvm-bcanalyzer.cpp.diff URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070704/b12afa40/attachment.ksh>

...ifter-llvm at gmx.at> writes: >> Maybe you can use the already available "include/llvm/Support/ >> Format.h"? > > Thanks, that simplifies the patch a lot. See the attached patch. It looks like something similar got applied back in r82772 on 9/25. > > Btw, llvm-bcanalyzer.cpp seems to also use fprintf -- does mixing it > with errs() cause problems and should it be converted to use format()? It would be nice to switch everything to use errs(). -Chris

...`/local/csaba/LLVM/build-release/tools/llc' make[1]: *** [llc/.makeall] Error 2 make[1]: *** Waiting for unfinished jobs.... llvm[2]: Compiling DiffLog.cpp for Release+Asserts build llvm[2]: Compiling ExecutionDriver.cpp for Release+Asserts build llvm[2]: Linking Release+Asserts executable llvm-bcanalyzer (without symbols) llvm[2]: Linking Release+Asserts executable llvm-mc (without symbols) llvm[2]: ======= Finished Linking Release+Asserts Executable llvm-bcanalyzer (without symbols) make[2]: Leaving directory `/local/csaba/LLVM/build-release/tools/llvm-bcanalyzer' llvm[2]: Compiling Difference...

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 seem to be doing so. Does anyone know what I should be doing? --Patrick

...clude\llvm\intrinsics_gen.vcproj" llc, "tools\llc\llc.vcproj" lli, "tools\lli\lli.vcproj" llvm-ar, "tools\llvm-ar\llvm-ar.vcproj" llvm-as, "tools\llvm-as\llvm-as.vcproj" llvm-bcanalyzer, "tools\llvm-bcanalyzer\llvm-bcanalyzer.vcproj" llvm-dis, "tools\llvm-dis\llvm-dis.vcproj" llvm-extract, "tools\llvm-extract\llvm-extract.vcproj" llvm-ld, "tools\llvm-ld\llvm-ld.vcproj" llvm-link...

...hat got fixed in a later release. I had problems with both versions, albeit slightly different ones. In both version the linking with the libfetish.a (part of the coreutils package) fails. With llvm-1.9, the library builds, and when I run these commands, they give the following results: Llvm-bcanalyzer: version number as 155730296, both file and module size as 267206, and the rest of the stuff is all 0s, 0% or NAN (not-a-number) Llvm-dis: Invalid bytecode signature: 72613C21 (Vers=0, Pos=4) Llvm-ar t: lists all the object files in the library Llvm-nm: libfetish.a: Success Llvm-ranlib: nothing...

.... The format of MODULE_CODE_{FUNCTION,GLOBALVAR,ALIAS,IFUNC,COMDAT} records would change so that their first operand would specify their names with a byte offset into the string table. (To allow for backwards compatibility, I would increment the bitcode version.) Here is what it would look like as bcanalyzer output: <MODULE_BLOCK> <VERSION op0=2> <COMDAT op0=0 ...> ; name = foo <FUNCTION op0=0 ...> ; name = foo <GLOBALVAR op0=4 ...> ; name = bar <ALIAS op0=8 ...> ; name = baz ; function bodies, etc. </MODULE_BLOCK> <STRTAB_BLOCK> <STRTAB_...

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 seem to be doing so. > > Does anyone know what I should be doing? > Looking at the LLVM 2.5 version, it prints out the count of the number of instructions as p...

...ld like some patches to be picked up. * RC1 LLVM and clang can be built on either msys/autoconf, msys/cmake and mingw/cmake. By CMake, all tests can run but 37 of LLVM and 5 of clang tests would fail. On mingw by configure tests cannot be executed. [PR9505] For compiling, I saw a warning, in llvm-bcanalyzer.cpp. (fixed in r127858) * RC1 3-stage build Please note configure and cmake will set optimizer option to -O2 by default even if clang++ were used. I overwrote for clang --with-optimize-option=-O3. Generated clang would be stable. But stage2-bin and stage3-bin will not match. Investigating. [PR62...

Reid, I finally figured out why my types were mismatching in my hand-decoded bytecode example when it worked fine in my actual code. It turns out that I was not leaving out the extension bits when I was hand decoding the VBRs. D'oh! Everything matches up now. Also figured out why the bcanalyzer is spitting out all those pointers to opaque. These types are forward references and they are getting printed out before they're resolved. Easy to fix. -- Robert.

I wrote in a few weeks ago about writing an independent implementation of Bitcode and updating the docs to be more complete. Attached is a patch to docs/BitCodeFormat.html that adds a lot of information that was previously only available by reading the source code. It also corrects some errors. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL:

...the "tradeoff" would be larger bytecode files. The use of >pointers to function types is not all that frequent so I wouldn't expect >it to save much. In any event, we're not going to do anything with this >until there are solid numbers. I'm working on improving llvm-bcanalyzer >to provide them. Right now I see pointer types being created for practically every literal type defined anyway. I doubt you'd see much file bloat due to pointer types being implied for everything. These pointer types are already being defined. However, I could see how it could concei...

...arantee that the "tradeoff" would be larger bytecode files. The use of pointers to function types is not all that frequent so I wouldn't expect it to save much. In any event, we're not going to do anything with this until there are solid numbers. I'm working on improving llvm-bcanalyzer to provide them. Reid -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040823/f72a1033/atta...