<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 12, 2013 at 4:36 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im"><br><div class="gmail_quote">On Tue, Nov 12, 2013 at 4:31 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">

<div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Where would the encoding schema be specified?</div></blockquote>

<div><br></div></div><div>Same question applies to a string encoding. We have to define the schema somewhere clearly. I'm just lobbying for the textual IR and the APIs to both operate directly on N fields, and just make the memory representation dense.</div>


</div></div></div></blockquote><div><br></div></div><div>The difference here is that debug info parsing code would know the schema externally - so the metadata itself wouldn't have to be self-describing or typed in any way. Just a flat series of bytes of a fixed size would be sufficient. (then leaving out the fields that refer to other IR constructs such as functions, variables, etc)<br>


<br>But if we could make general metadata generally more compact that'd be nice too and maybe sufficient/instead/not worth the added complexity in debug info code of pulling out fields in the debug info handling code.</div>

</blockquote></div><br></div>If it makes it possible for humans to read, author, and adjust debug info test cases, that would also be worth it IMO. I'm really unsatisfied by the reliance on C-code-in-comments to figure out what on earth the debug info came from.</div>
</div></blockquote><div><br></div><div>Fair point - it's a worthy goal I had only half considered in this context but may be worthwhile doing so.<br><br>But it may be at odds - increasing/changing the schema to the point of human readability may not be the most terse/memory-efficient representation for the actual compiler (I'm thinking of things like actually having self-describing textual representation with the names of fields, etc - but maybe it doesn't have to go that far).<br>
<br>Perhaps there's some middle ground, but it might be difficult to justify avoiding compile time improvements for the sake of editable/hand-authorable debug info test cases... we'll have to toss it around a bit more to see what shakes out in this space, I suspect.</div>
</div><br></div></div>