[LLVMdev] [RFC] Stripping unusable intrinsics

[Chris Lattner]

On Dec 22, 2014, at 2:56 PM, Chris Bieneman <beanz at apple.com> wrote:
> Circling back to Chandler on file size differences. Here are the highlights of what is different.
> 
> 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:
> 
> cmake -G "Sublime Text 2 - Ninja" -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=Yes -DLLVM_DISABLE_LLVM_DYLIB_ATEXIT=On -DCMAKE_INSTALL_PREFIX=/Users/cbieneman/dev/llvm-install/ -DLLVM_TARGETS_TO_BUILD="AArch64;ARM;X86" ../llvm
> 
> and built using Ninja.
> 
> Created a fresh build directory and built once as a baseline from the following revisions:
> 
> LLVM - ba05946
> lld - 33bd1dc
> clang - 1589d90 (With my patches applied)
> 
> 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:
> 
> find . -type f -exec stat -f '%N %z' '{}' + | sort
> 
> 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.

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.

It should be straight-forward to have something like LLVMInitializeX86Target/RegisterTargetMachine install the intrinsics into a registry.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141223/24548773/attachment.html>