<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">A binary search on a table would be possible, but we’d need to generate a table that was sorted. Today the order of intrinsics is really just the order that TableGen parses them in.<div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 22, 2014, at 1:34 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" class="">chisophugis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Mon, Dec 22, 2014 at 12:55 PM, Chris Bieneman<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:beanz@apple.com" target="_blank" class="">beanz@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Dec 22, 2014, at 12:02 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="">chandlerc@google.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Dec 19, 2014 at 3:39 PM, Chris Bieneman<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:beanz@apple.com" target="_blank" class="">beanz@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="">More diffs to enjoy.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">That’s about a 2% decrease in our library for WebKit.</div><div class=""><br class=""></div><div class="">See attached patches for llvm & clang.</div><span class=""><font color="#888888" class=""><div class=""></div></font></span></blockquote></div><br class="">FWIW, I still strongly object to this entire approach.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">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.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Without having looked at the code in question, could we maybe just have a binary search on a table? (possibly an existing table?)</div><div class=""><br class=""></div><div class="">-- Sean Silva</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">For example, what happens when an "impossible" enum is used to compute the value of some other enum?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">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.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">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.</div></div></div></blockquote><br class=""></span></div><div class="">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.</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">-Chris</div><br class=""></font></span></div><br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></blockquote></div></div></blockquote></div><br class=""></div></body></html>