<div>On Sun, Sep 30, 2012 at 9:09 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br></div><div><div><div><div class="gmail_extra"><div class="gmail_quote">
<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"><br><div><div class="im">
<div>On Sep 25, 2012, at 5:08 PM, Jan Voung <<a href="mailto:jvoung@chromium.org" target="_blank">jvoung@chromium.org</a>> wrote:</div><br><blockquote type="cite"><div>Hi all,</div><div><br></div><div>I've been looking into how to make llvm bitcode files smaller.  There is one simple change that appears to shrink linked bitcode files by about 15%.  See this spreadsheet for some rough data:</div>

<div><br></div><div><a href="https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E" target="_blank">https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E</a><br>
</div>
<div><br></div><div><br></div><div>The change is in how operand ids are encoded in bitcode files.  Rather than use an "absolute number" given by the ValueEnumerator, which counts up within a function, we can have the id be relative to the current instruction.</div>
</blockquote><div><br></div></div><div>Very cool.  This is the "obviously right" way to do it, I'm glad you've implemented it.  It looks like Duncan gave you a lot of feedback already, I'm looking forward to seeing the updated patch.  Thanks for tackling this Jan!</div>
<span class=""><font color="#888888"><div><br></div><div>-Chris</div></font></span></div></div>
</blockquote></div><br></div></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><div>Thanks for taking a look!  I wasn't sure of better way to toggle this behavior at the module level vs the function level.  The options I toyed with were:</div>
<div><br></div><div>  (a) bump MODULE_CODE_VERSION from 0 to 1</div><div>  (b) add a new optional module code to identify the change</div><div>  (c) stick with the approach in the first patch, which used a new function block ID value, then check that all the function blocks uniformly have the newer ID instead of mix of the old and new.</div>
</div><div><br></div><div><br></div><div>for option (a) there hasn't been a version bump before(?) and I wasn't sure when that is appropriate.</div><div>for option (b) it seems like it's really indicating a version change and not doing anything else, so could have been done more directly with (a)</div>
<div>for option (c) it ends up creating a new block ID that overlaps with the existing function one and that would be first one to do that?</div><div><br></div><div>Thanks again Duncan for the review, and Renato for the suggestion of looking into SLEB. Attached is an updated patch which toggles the change at the module level (done with option a), and uses signed VRBs for phis, </div>
<div><div><br></div><div>- Jan</div><div><div></div></div></div></div>