<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 11, 2013 at 11:29 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank" class="cremed">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Manman (and llvmdev),<br>
<br>
I filed these two bugs to track the ideas that I was cooking:<br>
<br>
<a href="http://llvm.org/bugs/show_bug.cgi?id=17891" target="_blank" class="cremed">http://llvm.org/bugs/show_bug.cgi?id=17891</a><br>
<a href="http://llvm.org/bugs/show_bug.cgi?id=17892" target="_blank" class="cremed">http://llvm.org/bugs/show_bug.cgi?id=17892</a><br>
<br>
TL;DR: I'm saying we should go from:<br>
<br>
        !14 = metadata !{i32 786445, metadata !1, metadata !10, metadata !"y", i32 3, i64 32, i64 32, i64 32, i32 0, metadata !13}<br>
to:<br>
        !14 = metadata !"v12,14,y,3,0,32,32,32"(metadata !1, metadata !13)<br></blockquote><div><br></div><div>So, I like where you're going here, but a few tweaks.</div><div><br></div><div>First, there are two things going on here: removing an indirection through a referenced metadata node and flattening N values into a string inclusion. Removing the indirection seems obvious strict goodness, my comments are about the second part.</div>
<div><br></div><div>I'm moderately opposed to just encoding these in a string format. I think we can do something substantially better both for space, time, and readability. Fundamentally, there is no reason for the original metadata node you describe to not *encode* its operands into a dense bit-packed blob of memory. We can still expose APIs that manipulate them as separate entities, and have the AsmPrinter and AsmParser map back and forth with nice human-readable forms. But even a simple varint encoding will be both smaller and faster than ascii.</div>
<div><br></div><div>Just to be clear, I still want the nice format (much like your proposed format, but maybe with the numbers outside of the "s) in the textual IR, I just think we should use a more direct and efficient in-memory encoding (and in-bitcode encoding if that isn't already suitably dense).</div>
</div></div></div>