[LLVMdev] [RFC] Stripping unusable intrinsics

[Chris Bieneman]

> On Dec 22, 2014, at 12:02 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> 
> On Fri, Dec 19, 2014 at 3:39 PM, Chris Bieneman <beanz at apple.com <mailto: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.

The vast majority of the space savings comes from reduced code size (not constant data), which was somewhat surprising to me at first, but in retrospect makes a lot of sense. In particular the TableGen-generated code that parses intrinsic names to resolve strings->ids, is pretty massive.

> 
> For example, what happens when an "impossible" enum is used to compute the value of some other enum?

This could be un-affected. My clang changes only impact when impossible enums are used in conditional statements and switch statements. That aside, in our specific use I’d be pretty terrified if we’re using the value of intrinsic ids to compute other intrinsic ids because I don’t believe we have any guarantee of the ordering or values of intrinsic ids. From looking at the TableGen backend it looks to me like the id is really just the index into the records list, which is constructed in order of the parsing, and those indexes are used all over the place and assumed to match.

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

The way I handled numbering in my patch was to make the impossible enums immediately follow the last possible enum, and it all worked fine.

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

I understand all your points here. Independent of whether or not this is the right approach for handling intrinsics I’m going to clean-up and propose my patches to clang to add the attribute because it does seem useful to me.

-Chris

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