[LLVMdev] [RFC] Stripping unusable intrinsics

Chris Lattner
2014-12-23T17:45:18Z

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>