
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Sjoerd,<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">Your tool looks very interesting and useful. I think we are very interested. In fact, I am looking at code-size problems at the moment, and will give it a try. I think we can help with the review too.</div></blockquote><div class=""><br class=""></div>That would be great!</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">FWIW, when I investigate code-size problems, I usually start looking at the final linked image (for context, that's mostly baremetal images). Unused sections and functions will be removed by the linker, which e.g. avoids unnecessary analysing them which may happen when you only look at object files. I use a downstream tool for binaries that list the code-size per function. When I generate such a report for different images, I can easily diff them and see where codesize difference are the biggest. I then isolate a function, compile it with debug and print-after-all, so that I can do a diff again where changes are introduced. And when image sizes are small, and library inclusion is thus relatively important, the linker in verbose mode telling me why and which objects and functions are included is extremely useful too.</div></blockquote><br class=""></div><div class="">I have a similar tool! :)</div><div class=""><br class=""></div><div class="">I think that you’re right wrt looking at functions that actually appear in the final linked image. In my experience, this is the common case. (My personal script just looks at the output of llvm-nm)</div><div class=""><br class=""></div><div class="">I think that combining the two approaches could be interesting. By using remarks in conjunction with the symbols present in the final linked image, it should be possible to signify to the user if a function was eliminated by the compiler (and which pass did it) or the linker.</div><div class=""><br class=""></div><div class="">I think the default output should be something like this:</div><div class=""><br class=""></div><div class="">- Only show functions that appear in the binary</div><div class="">- If a function appears in one image, but not the other, check if there is a remark stating that its instruction count went to 0. If there is, state that it was eliminated by the compiler.</div><div class="">- … If there isn’t, state that it was eliminated by the linker</div><div class=""><div><br class=""></div><div>I think that for a first pass, just to get the functionality going, I’d like to just focus on the remarks-based diffing. After that, I think it would be a natural step to add information about the actual binary to the tool as well.</div><div><br class=""></div><div>- Jessica</div><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 13, 2019, at 11:00 pm, Sjoerd Meijer <<a href="mailto:Sjoerd.Meijer@arm.com" class="">Sjoerd.Meijer@arm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class="">Hi Jessica,</div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class=""><br class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class="">We often have exactly the same problem:</div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class=""><br class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class="">> <span style="color: rgb(32, 31, 30); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 15px;" class="">I frequently find that I want to quickly find out which functions have changed the most in size when I compile a program with one version of the compiler and another version of the compiler.</span><br class=""><br class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class="">Your tool looks very interesting and useful. I think we are very interested. In fact, I am looking at code-size problems at the moment, and will give it a try. I think we can help with the review too.</div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class=""><br class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class="">FWIW, when I investigate code-size problems, I usually start looking at the final linked image (for context, that's mostly baremetal images). Unused sections and functions will be removed by the linker, which e.g. avoids unnecessary analysing them which may happen when you only look at object files. I use a downstream tool for binaries that list the code-size per function. When I generate such a report for different images, I can easily diff them and see where codesize difference are the biggest. I then isolate a function, compile it with debug and print-after-all, so that I can do a diff again where changes are introduced. And when image sizes are small, and library inclusion is thus relatively important, the linker in verbose mode telling me why and which objects and functions are included is extremely useful too.</div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class=""><br class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class="">Cheers,</div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class="">Sjoerd.</div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class=""><br class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class=""><br class=""></div><div id="appendonsend" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class=""><br class=""></div><hr tabindex="-1" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline-block; width: 804.578125px;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""></span><div id="divRplyFwdMsg" dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><font face="Calibri, sans-serif" style="font-size: 11pt;" class=""><b class="">From:</b><span class="Apple-converted-space"> </span>llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" class="">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Jessica Paquette via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>14 June 2019 00:30<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Jessica Paquette via llvm-dev<br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>[llvm-dev] [RFC] Remarks-based code size analysis tool</font><div class=""> </div></div><div class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; line-break: after-white-space;">Hi everyone,<div class=""><br class=""></div><div class="">I frequently find that I want to quickly find out which functions have changed the most in size when I compile a program with one version of the compiler and another version of the compiler.</div><div class=""><br class=""></div><div class="">Optimization remarks provide deeper insight into what the compiler does to individual functions during the compilation process. A tool based off of remarks would give us the means to say *exactly* what a pass did to a function during the compilation process. We also have remarks from the asm-printer which tell us the number of instructions in a function at any given time.</div><div class=""><br class=""></div><div class="">It’s now possible to access remarks through object files. So, I thought it would be an interesting experiment to write a C++ tool using the new remarks API to write a simple size tool. A size tool using remarks would be able to tell us about the following things:</div><div class=""><br class=""></div><div class="">1) Which functions grew the most in size between one compilation and another compilation</div><div class="">2) Which functions were/were not inlined between compilations (and similar insights into other passes)</div><div class="">3) Which compiler passes caused the largest increases in each function</div><div class=""><br class=""></div><div class="">I have a prototype for a size tool which accomplishes (1) using asm-printer remarks. (2) and (3) can be accomplished by searching for remarks corresponding to interesting passes and by searching for size-info remarks respectively. For now, I just decided to implement the minimum set of features for a useful tool. The patch is available here:</div><div class=""><br class=""></div><div class=""><a href="https://reviews.llvm.org/D63306" class="">https://reviews.llvm.org/D63306</a></div><div class=""><br class=""></div><div class="">The tool in the patch works like this:</div><div class=""><br class=""></div><div class="">$ ./sizediff old_version_of_program new_version_of_program</div><div class=""><br class=""></div><div class="">And it produces output like this:</div><div class=""><br class=""></div><div class="">function_name old_instruction_count new_instruction_count delta</div><div class=""><br class=""></div><div class="">This output can tell me the following things:</div><div class=""><br class=""></div><div class="">- Which functions were not present in old_version_of_program (they have a size of 0)</div><div class="">- Which functions were not present in new_version_of_program (same idea)</div><div class="">- Which functions grew the most</div><div class="">- Which functions shrunk the most</div><div class=""><br class=""></div><div class="">For a concrete example of the output, here’s some output I got by compiling the stepanov_container benchmark for AArch64 with -Os and -O3 respectively:</div><div class=""><br class=""></div><div class=""><a href="https://hastebin.com/hucexocuxi.md" class="">https://hastebin.com/hucexocuxi.md</a></div><div class=""><br class=""></div><div class="">If anyone is interested, feel free to try it out/review/etc. I think that a tool like this would be quite useful. :)</div><div class=""><br class=""></div><div class="">- Jessica</div></div><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.</span></div></blockquote></div><br class=""></div></body></html>