<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 19, 2014 at 3:39 PM, Chris Bieneman <span dir="ltr"><<a href="mailto:beanz@apple.com" target="_blank">beanz@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>More diffs to enjoy.</div><div><br></div><div>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><br></div><div>That’s about a 2% decrease in our library for WebKit.</div><div><br></div><div>See attached patches for llvm & clang.</div><span class="HOEnZb"><font color="#888888"><div></div></font></span></blockquote></div><br>FWIW, I still strongly object to this entire approach.</div><div class="gmail_extra"><br></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></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 class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></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></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>