<div class="gmail_quote">On 25 February 2010 09:54, Devang Patel <span dir="ltr"><<a href="mailto:dpatel@apple.com">dpatel@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div style=""><div class="im"><br><div><div>On Feb 25, 2010, at 12:30 AM, Nick Lewycky wrote:</div><br><blockquote type="cite"><span style="border-collapse: separate; font-family: Verdana; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">Author: nicholas<br>

Date: Thu Feb 25 02:30:17 2010<br>New Revision: 97132<br><br>URL:<span> </span><a href="http://llvm.org/viewvc/llvm-project?rev=97132&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=97132&view=rev</a><br>

Log:<br>Make the side-numbering of instructions used by metadata (which is needed to<br>keep track of instructions that return void) per-function</span></blockquote></div><br></div><div>It is used to connect metadata with respective instruction when metadata is attached with an instruction.</div>

</div></blockquote><div><br>Yes of course. The not-so-obvious part is why you needed a side-numbering instead of just using value IDs which is the basis for the rest of the bitcode format. The problem is that the value enumerator doesn't number void instructions, such as "ret", where you want to attach metadata.<br>

Just making the VE enumerate void instructions would break backwards compatibility too, since bitcode relies on the reader and writer to have a matching numbering scheme where we don't store the concrete numbers.<br>
<br>
After thinking about this, I think the right way to go forward is to create new FUNC_CODE_INST_FOO entries for the void instructions so that the bitcode reader knows it's expected to number them and the writer's VE can number everything.<br>

<br>In any event, I'm happy now that the bug is fixed and the format is designed well enough that we can keep compatibility with future changes. I'm not planning any more changes here.<br><br>Nick</div></div><br>