Now with a compressed patch. Sorry for the duplication. Working on another patch I noticed quiet a bit of code in lib/MC that uses MC types, but is not used by MC itself or by any MC clients other than llvm-objdump. As an experiment to see how big this was, I created a MC2 library (patch attached). The results are interesting. In a Release+Asserts shared build I get 811464 lib/libLLVMMC.so 272296 lib/libLLVMMCParser.so 152744 lib/libLLVMMC2.so 61248 lib/libLLVMMCJIT.so 22008 lib/libLLVMMCDisassembler.so Note how the new library is the third largest. Now, what is this code? From the the commit messages it looks like it is for "fancy" disassembly with CFG reconstruction. Is it complementary to the existing MCDisassembler library? Should the code be moved there instead? Should we have a MCDisassemblerCFG library? Splitting this library would also make it trivial to remove the MC -> Object dependency. Cheers, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: t.patch.bz2 Type: application/x-bzip2 Size: 22829 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140629/d7fbd46a/attachment.bin>
On Sat, Jun 28, 2014 at 10:25 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> Now with a compressed patch. Sorry for the duplication. > > Working on another patch I noticed quiet a bit of code in lib/MC that > uses MC types, but is not used by MC itself or by any MC clients other > than llvm-objdump. > > As an experiment to see how big this was, I created a MC2 library > (patch attached). The results are interesting. In a Release+Asserts > shared build I get > > 811464 lib/libLLVMMC.so > 272296 lib/libLLVMMCParser.so > 152744 lib/libLLVMMC2.so > 61248 lib/libLLVMMCJIT.so > 22008 lib/libLLVMMCDisassembler.so > > Note how the new library is the third largest. > > Now, what is this code? From the the commit messages it looks like it > is for "fancy" disassembly with CFG reconstruction. Is it > complementary to the existing MCDisassembler library? Should the code > be moved there instead? Should we have a MCDisassemblerCFG library? > > Splitting this library would also make it trivial to remove the MC -> > Object dependency. >Splitting it off (at least into MCDisassembler) sounds like a good idea, Rafael. [I wonder if this will help making a custom-built llc that doesn't do disassembly smaller] Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140629/0655e535/attachment.html>
Hi Rafael, There have been a few attempts to do CFG (and more) analysis up from MC. Getting disassembly annotations is one of the interesting use cases, to be sure, but it There’s nothing intrinsically linking the logic to disassembly other than that being the most common source from which one would want to do this sort of reverse compilation sort of analysis. There’s no inherent reason I know of to not split it out into something separate. Looks like it’ll be a nontrivial win for code size, too. -Jim> On Jun 28, 2014, at 10:25 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > Now with a compressed patch. Sorry for the duplication. > > Working on another patch I noticed quiet a bit of code in lib/MC that > uses MC types, but is not used by MC itself or by any MC clients other > than llvm-objdump. > > As an experiment to see how big this was, I created a MC2 library > (patch attached). The results are interesting. In a Release+Asserts > shared build I get > > 811464 lib/libLLVMMC.so > 272296 lib/libLLVMMCParser.so > 152744 lib/libLLVMMC2.so > 61248 lib/libLLVMMCJIT.so > 22008 lib/libLLVMMCDisassembler.so > > Note how the new library is the third largest. > > Now, what is this code? From the the commit messages it looks like it > is for "fancy" disassembly with CFG reconstruction. Is it > complementary to the existing MCDisassembler library? Should the code > be moved there instead? Should we have a MCDisassemblerCFG library? > > Splitting this library would also make it trivial to remove the MC -> > Object dependency. > > Cheers, > Rafael > <t.patch.bz2>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev