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 ../*.dylib34236 ../libLLVM-ARM-only-after.dylib 34732 ../libLLVM-ARM-only-before.dylib These savings are substantial for our use case. -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 <mailto:beanz at apple.com>> wrote: >> On Dec 10, 2014, at 4:22 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: >> >> >> >> On Wed Dec 10 2014 at 3:57:25 PM Chris Bieneman <beanz at apple.com <mailto: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 <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <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/a6b6433d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: strip_intrinsics.diff Type: application/octet-stream Size: 18988 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/a6b6433d/attachment.obj> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/a6b6433d/attachment-0001.html>
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>
That library isn’t actually representative of what we ship in terms of it’s overall size. For that test I only stripped unused backends. We also strip unused functionality, but we also have out-of-tree functionality that we add in. I our shipping library for WebKit is under 15MB, which would put this closer to ~3% savings. As far as low-hanging fruit go, that’s a pretty big one. -Chris> On Dec 11, 2014, at 4:43 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Thu, Dec 11, 2014 at 4:23 PM, Chris Bieneman <cbieneman at apple.com <mailto: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 <mailto:echristo at gmail.com>> wrote: >> >> >> >> On Wed Dec 10 2014 at 5:37:06 PM Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >>> On Dec 10, 2014, at 4:22 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: >>> >>> >>> >>> On Wed Dec 10 2014 at 3:57:25 PM Chris Bieneman <beanz at apple.com <mailto: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 <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <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/60baedc9/attachment.html>