<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 8, 2014 at 4:29 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:duncan@exonsmith.com" target="_blank">duncan@exonsmith.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":57z" class="a3s" style="overflow:hidden">I'm looking to tackle PR5680 [1].  The primary goal is to prevent<br>

behaviour changes in passes that depend on the order of use lists when<br>
serializing/deserializing the IR to a bitcode file (.bc) between passes.<br>
<br>
Here's a quick high-level summary:<br>
<br>
  - When writing bitcode, calculate what the use list order will be<br>
    after reading the bitcode.  (Assumption: the order is predictable.)<br>
<br>
  - Write a use-list-order-diff in a new (optional) section in the<br>
    bitcode.<br>
<br>
  - When reading bitcode, apply the use-list-order-diff to restore the<br>
    original use list order.<br></div></blockquote></div><br>So, it may be totally obvious, but is there a reason not to embed the observed order of the use list in the bitcode more directly? This seems quite round-about, and I'm curious why its needed.</div>
</div>