[LLVMdev] [RFC] Stripping unusable intrinsics

Sean Silva chisophugis at gmail.com
Thu Dec 11 16:43:17 PST 2014


On Thu, Dec 11, 2014 at 4:23 PM, Chris Bieneman <cbieneman at apple.com> wrote:
>
> I’ve got some new patches and some numbers.
>
> The patches are all the changes required to strip intrinsics using the
> preprocessor defines I showed in my earlier patches. It actually isn’t that
> much change to LLVM. Clang will need similar changes too. There were only 9
> files that referenced target intrinsics outside the corresponding target.
>
> These patches are still WIP, and there is some nastiness, but they work.
>
> Using these patches I see about 500k reduction in binary size when
> building libLLVM.dylib with just the ARM backend enabled.
>
> > du -k ../*.dylib
> 34236 ../libLLVM-ARM-only-after.dylib
> 34732 ../libLLVM-ARM-only-before.dylib
>
> These savings are substantial for our use case.
>

I'm sort of curious that ~1.5% savings is "substantial". It smells of
diminishing returns/microoptimization. If there is really such a dire need
for size, surely there are whole parts of the API that aren't used by your
application and could be stripped for much greater benefit?

-- Sean Silva


>
> -Chris
>
>
> On Dec 10, 2014, at 5:39 PM, Eric Christopher <echristo at gmail.com> wrote:
>
>
>
> On Wed Dec 10 2014 at 5:37:06 PM Chris Bieneman <beanz at apple.com> wrote:
>
>> On Dec 10, 2014, at 4:22 PM, Eric Christopher <echristo at gmail.com> wrote:
>>
>>
>>
>> On Wed Dec 10 2014 at 3:57:25 PM Chris Bieneman <beanz at apple.com> wrote:
>>
>>> llvm-dev,
>>>
>>> In my ongoing saga to improve LLVM for embedded use, we would like to
>>> support stripping out unused intrinsics based on the LLVM targets actually
>>> being built.
>>>
>>> I’ve attached two patches.
>>>
>>> The first is a new flag for tablegen to take a list of targets. If
>>> passed tablegen will only emit intrinsics that either have empty target
>>> prefixes, or target prefixes matching one of the targets in the list. If
>>> the flag is not passed the behavior is unchanged. This patch can land today
>>> (subject to review).
>>>
>>> The second patch is a WIP, and adds support to the CMake build system
>>> for using the new tablegen flag, and for generating a new
>>> llvm/Config/llvm-targets.h header which contains defines for each target
>>> specified with LLVM_TARGETS_TO_BUILD.
>>>
>>> This new header will allow us to #ifdef code using target-specific
>>> intrinsics outside the targets, thus allowing us to strip out all the
>>> unused intrinsics.
>>>
>>>
>> I like the general idea and, as you asked on irc, will happily help with
>> the autoconf changes. Do you have a small (even pseudo) code example of
>> what the changes to the middle end machinery will look like?
>>
>>
>> The big change required outside the patches on my first email is that any
>> use of a target intrinsic will need to be #ifdef’d. I haven’t tracked all
>> of those down yet.
>>
>>
> That's a little gross. I wonder if there's a better abstraction for this -
> I think the "check if a preprocessor define" is valid would be painful for
> maintenance and testing.
>
> -eric
>
>
>> -Chris
>>
>>
>> -eric
>>
>>
>>> -Chris
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/fb5c6274/attachment.html>


More information about the llvm-dev mailing list