[LLVMdev] [RFC] Stripping unusable intrinsics

[Chandler Carruth]

On Fri, Dec 19, 2014 at 3:39 PM, Chris Bieneman <beanz at apple.com> wrote:

> More diffs to enjoy.
>
> I’ve updated my tablegen patches to work with the clang::impossible_enum
> attribute. With these changes I am seeing the same code size regressions
> that #ifdefs were showing — without all the ifdefs.
>
> That’s about a 2% decrease in our library for WebKit.
>
> See attached patches for llvm & clang.
>

FWIW, I still strongly object to this entire approach.

If we want to add support for this magical attribute to clang, fine, but
honestly I don't think it's that relevant for the issue at hand.

The critical question to my mind is why are intrinsics taking up so much
space. I think it would be much more profitable to make intrinsics compact
than to add hacks to LLVM to exclude target intrinsics entirely. Especially
based on a fairly subtle and magical enum attribute. It changes too much of
the meaning of enums.

For example, what happens when an "impossible" enum is used to compute the
value of some other enum? At what number do you start up numbering those
enums listed after an impossible enum? I see no easy, obvious, and
unsurprising answers here. I don't want to have to think this much about
something that should be *extremely* basic.

If the target-independent optimizer is being bloated by code to handle
optimizing target-specific intrinsics, we should look at factoring such
code into an IR-level transform library in the target that can be inserted
into the optimizer pass pipeline like anything else. But I have my doubts
that this is the cause.

If the target-specific intrinsics are carrying a huge amount of code in the
core IR library in order to support parsing, serializing, printing, etc.,
we should really find a more compact way of doing this. I cannot fathom how
this could require 500kb of data (or text) to handle. We're doing something
deeply wrong with intrinsics, and I think it is a mistake to pursue
anything until we understand that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141222/da07143d/attachment.html>