<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 23, 2014, at 10:19 AM, Bob Wilson <<a href="mailto:bob.wilson@apple.com" class="">bob.wilson@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 23, 2014, at 9:45 AM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Dec 22, 2014, at 2:56 PM, Chris Bieneman <<a href="mailto:beanz@apple.com" class="">beanz@apple.com</a>> wrote:<div class=""><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Circling back to Chandler on file size differences. Here are the highlights of what is different.<div class=""><br class=""></div><div class="">For my analysis I built LLVM and Clang using a clang built with my patches. The same clang was used for the baseline and the stripped build. I used the following CMake command:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-family: 'Andale Mono';" class=""><span style="color: rgb(69, 123, 249); background-color: rgb(0, 0, 0);" class="">cmake</span><span style="color: rgb(41, 249, 20); background-color: rgb(0, 0, 0);" class=""> </span><font color="#38c1ff" class=""><span style="background-color: rgb(0, 0, 0);" class="">-G</span></font><span style="color: rgb(41, 249, 20); background-color: rgb(0, 0, 0);" class=""> </span><span style="color: rgb(175, 173, 36); background-color: rgb(0, 0, 0);" class="">"Sublime Text 2 - Ninja"</span><span style="color: rgb(41, 249, 20); background-color: rgb(0, 0, 0);" class=""> </span><font color="#38c1ff" class=""><span style="background-color: rgb(0, 0, 0);" class="">-DCMAKE_BUILD_TYPE=Release</span></font><span style="color: rgb(41, 249, 20); background-color: rgb(0, 0, 0);" class=""> </span><font color="#38c1ff" class=""><span style="background-color: rgb(0, 0, 0);" class="">-DLLVM_BUILD_LLVM_DYLIB=Yes</span></font><span style="color: rgb(41, 249, 20); background-color: rgb(0, 0, 0);" class=""> </span><font color="#38c1ff" class=""><span style="background-color: rgb(0, 0, 0);" class="">-DLLVM_DISABLE_LLVM_DYLIB_ATEXIT=On</span></font><span style="color: rgb(41, 249, 20); background-color: rgb(0, 0, 0);" class=""> </span><font color="#38c1ff" class=""><span style="background-color: rgb(0, 0, 0);" class="">-DCMAKE_INSTALL_PREFIX=/Users/cbieneman/dev/llvm-install/</span></font><span style="color: rgb(41, 249, 20); background-color: rgb(0, 0, 0);" class=""> </span><font color="#38c1ff" class=""><span style="background-color: rgb(0, 0, 0);" class="">-DLLVM_TARGETS_TO_BUILD=</span></font><span style="color: rgb(175, 173, 36); background-color: rgb(0, 0, 0);" class="">"AArch64;ARM;X86"</span><span style="color: rgb(41, 249, 20); background-color: rgb(0, 0, 0);" class=""> </span><span style="color: rgb(56, 193, 255); background-color: rgb(0, 0, 0); text-decoration: underline;" class="">../llvm</span></div></div><div class=""><br class=""></div><div class="">and built using Ninja.</div><div class=""><br class=""></div><div class="">Created a fresh build directory and built once as a baseline from the following revisions:</div><div class=""><br class=""></div><div class="">LLVM - ba05946</div><div class="">lld - 33bd1dc</div><div class="">clang - 1589d90 (With my patches applied)</div><div class=""><br class=""></div><div class="">I then applied my tablegen and CMake patches, made a new build directory, and built a second time. I then compared the file sizes between the two directories by diffing the output of:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-family: 'Andale Mono'; color: rgb(56, 193, 255); background-color: rgb(0, 0, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #457bf9" class="">find</span><span style="font-variant-ligatures: no-common-ligatures; color: #29f914" class=""> </span>.<span style="font-variant-ligatures: no-common-ligatures; color: #29f914" class=""> </span>-type<span style="font-variant-ligatures: no-common-ligatures; color: #29f914" class=""> </span>f<span style="font-variant-ligatures: no-common-ligatures; color: #29f914" class=""> </span>-exec<span style="font-variant-ligatures: no-common-ligatures; color: #29f914" class=""> </span>stat<span style="font-variant-ligatures: no-common-ligatures; color: #29f914" class=""> </span>-f<span style="font-variant-ligatures: no-common-ligatures; color: #29f914" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #afad24" class="">'%N %z'</span><span style="font-variant-ligatures: no-common-ligatures; color: #29f914" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #afad24" class="">'{}'</span><span style="font-variant-ligatures: no-common-ligatures; color: #29f914" class=""> </span>+<span style="font-variant-ligatures: no-common-ligatures; color: #29f914" class=""> | </span><span style="font-variant-ligatures: no-common-ligatures; color: #457bf9" class="">sort</span></div></div><div class=""><br class=""></div><div class="">The biggest benefits are an 11% reduction in size for libLLVMCore, which is mostly due to Function.cpp.o reducing in size by 300KB (almost 39%). The biggest thing in there that would contribute to actual code size is the almost 28,000 line switch statement that provides the implementation for Function::lookupIntrinsicID.</div></div></div></blockquote><br class=""></div><div class="">That makes sense. It sounds like there is a better design here: we should move to a model where intrinsic tables are registered by any targets that are activated. That would allow the intrinsic tables (including these switch/lookup mapping tables) to be in the target that uses them.</div><div class=""><br class=""></div><div class="">It should be straight-forward to have something like LLVMInitializeX86Target/RegisterTargetMachine install the intrinsics into a registry.</div></div></div></blockquote><br class=""></div><div class="">I tried doing that a few years ago. It’s not nearly as easy as it sounds because we’ve got hardcoded references to various target intrinsics scattered throughout the code.</div></div></div></blockquote><br class=""></div><div>I was just writing to say exactly this. There are a number of ways we could work toward something like this. I’m completely in favor of a world where Intrinsics are properties of the targets and don’t leach out, however today they do in a lot of places.</div><div><br class=""></div><div>Some of these places could be replaced with subtarget hooks with very little issue, and we could certainly have target initialization register intrinsics.</div><div><br class=""></div><div>One cost of having intrinsics live in the targets is that we actually get some pretty substantial savings today in our constant data size by having all the intrinsics generated together. Today Intrinsic IDs are used as indices to tables that map to other characteristics, and there is uniquing performed on the tables to reduce their size.</div><div><br class=""></div><div>One possible solution would be to only have the intrinsic enum remain part of the IR library, but have everything else get broken up by target. We could make this work by having Tablegen specify enum values using the high-order bits to signify which target, and the low-order bits to signify the index into that target’s intrinsic tables. This would probably get us a big chunk of the overall code size savings.</div><div><br class=""></div><div>I also think that simply sorting the intrinsics by name, and doing a binary sort like Sean suggested should allow us to save a lot of code size, and probably make this faster too.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>