[LLVMdev] [RFC] Stripping unusable intrinsics

[Sean Silva]

On Mon, Dec 22, 2014 at 12:55 PM, Chris Bieneman <beanz at apple.com> wrote:

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

Without having looked at the code in question, could we maybe just have a
binary search on a table? (possibly an existing table?)

-- Sean Silva


>
>
> 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
>
>
> _______________________________________________
> 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/20141222/6bd94bab/attachment.html>