<br><br><div class="gmail_quote">On Wed Dec 10 2014 at 4:28:18 PM Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 11, 2014 at 1:22 AM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Wed Dec 10 2014 at 3:57:25 PM Chris Bieneman <<a href="mailto:beanz@apple.com" target="_blank">beanz@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">llvm-dev,<br>
<br>
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.<br>
<br>
I’ve attached two patches.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br></blockquote><div><br></div></div></div><div>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?</div></blockquote></div><br></div></div><div dir="ltr"><div class="gmail_extra">FWIW, I'm actually kinda terrified of the changes this will require throughout the optimizer.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div></blockquote><div><br></div><div><br></div><div>That's kinda why I was interested in what it looked like in changing the middle end :)</div><div><br></div><div>Numbers are good though.</div><div><br></div><div>-eric </div></div>