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. -Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-build.diff Type: application/octet-stream Size: 1761 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141210/d4d0f479/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: tablegen.diff Type: application/octet-stream Size: 1524 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141210/d4d0f479/attachment-0001.obj>
How much code is there that looks at target specific intrinsics from generic IR passes? Can we move this code into something like TargetTransformInfo? On Wed, Dec 10, 2014 at 3:53 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. > > -Chris > > > _______________________________________________ > 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/20141210/9645423c/attachment.html>
Chris, How much do you save by doing this? -Hal ----- Original Message -----> From: "Chris Bieneman" <beanz at apple.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, December 10, 2014 5:53:31 PM > Subject: [LLVMdev] [RFC] Stripping unusable intrinsics > > > > 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. > > -Chris > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On Thu, Dec 11, 2014 at 1:02 AM, Reid Kleckner <rnk at google.com> wrote:> How much code is there that looks at target specific intrinsics from > generic IR passes?I suspect quite a bit transitively. ValueTracking, constant folding, instsimplify, instcombine, etc.> Can we move this code into something like TargetTransformInfo?Yikes, no. That's behind an abstract common interface. All of the above are specialized specific uses of narrow interfaces in relative hot paths of the optimizer. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/29ac34f0/attachment.html>
> On Dec 10, 2014, at 4:02 PM, Reid Kleckner <rnk at google.com> wrote: > > How much code is there that looks at target specific intrinsics from generic IR passes? Can we move this code into something like TargetTransformInfo?InstCombineCalls does some of this. Ideally we’d move this to something like InstCombineCalls_X86, etc. That or at the very least a method for each target which is #ifdef’ed . There’s also code in SelectionDAGBuilder for lowering some target specific intrinsics. Thanks, Pete> > On Wed, Dec 10, 2014 at 3:53 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. > > -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 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/20141210/5eaab245/attachment.html>
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? -eric> -Chris > > _______________________________________________ > 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/00e42810/attachment.html>
On Thu, Dec 11, 2014 at 1:22 AM, 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? >FWIW, I'm actually kinda terrified of the changes this will require throughout the optimizer. I think it will be particular hard when doing canonicalization to avoid subtle bugs where the lack of a code path to handle a target intrinsic causes a different ranking of patterns... Maybe my fears are misplaced here, but it isn't yet apparent how to separate all of the uses of target intrinsics in the optimizer out of the surrounding code cleanly, without severely negatively impacting the readability and maintainability of the code. However, if the savings of doing this are massive, then perhaps its worth all the complexity it brings. But if the savings are small, I'm much more skeptical. So I feel like we really need an answer to Hal's question. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/1aaf5664/attachment.html>
> 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 <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. -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/20141210/6dd73795/attachment.html>
Random shower thought: I think the markup can be minimized if it only appears once in the header where the enums are defined instead of at every place where the enums are used. Then we could value propagate that certain enum values are never possible where they're checked for. That should generally be able to strip the same set of stuff but use less markup. Alex On Dec 10, 2014, at 3:53 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. > > -Chris > > <cmake-build.diff><tablegen.diff>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Ok… I bit. Alex’s proposal here is really compelling to me because it means that the required changes to make this work would be more limited. Specifically a clang attribute could give us all the benefits of #ifdefs throughout the code without the maintenance burden. So, being the silly person I am, I wrote the patches for clang. I’ve never done any frontend hacking before, so take these with giant cellars of salt, but the concept seems sound to me. The patches do the following: (1) Add a new C++11-style [[impossible_enum]] attribute (2) Any case statement that has [[impossible_enum]] applied to it is not emitted during IRGen - the bodies are always emitted so as not to interfere with fall through, but blocks that cannot be entered are optimized away (3) Equality comparison against [[impossible_enum]] values are always false, all other comparisons are always true There was some discussion on IRC today whether or not this was the right way to do this, but I thought I’d send these patches out anyways so people can take a look. The attached diffs are for clang, I’ve also attached a c++ test file. -Chris> On Dec 16, 2014, at 12:09 PM, Alex Rosenberg <alexr at ohmantics.com> wrote: > > Random shower thought: > > I think the markup can be minimized if it only appears once in the header where the enums are defined instead of at every place where the enums are used. Then we could value propagate that certain enum values are never possible where they're checked for. That should generally be able to strip the same set of stuff but use less markup. > > Alex > > On Dec 10, 2014, at 3:53 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. >> >> -Chris >> >> <cmake-build.diff><tablegen.diff>_______________________________________________ >> 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/20141218/29d17e5a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: impossible_enum.cpp Type: application/octet-stream Size: 937 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/29d17e5a/attachment.obj> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/29d17e5a/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: impossible_enum.diff Type: application/octet-stream Size: 7137 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/29d17e5a/attachment-0001.obj> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/29d17e5a/attachment-0002.html>