[LLVMdev] [RFC] Stripping unusable intrinsics

Eric Christopher echristo at gmail.com
Wed Dec 10 16:29:13 PST 2014

On Wed Dec 10 2014 at 4:28:18 PM Chandler Carruth <chandlerc at google.com>

> 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.

That's kinda why I was interested in what it looked like in changing the
middle end :)

Numbers are good though.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/75413c77/attachment.html>

More information about the llvm-dev mailing list