[LLVMdev] How to reduce the footprint of MDNodes? (About the comment you made at BOF LTO)

[David Blaikie]

On Tue, Nov 12, 2013 at 4:36 PM, Chandler Carruth <chandlerc at google.com>wrote:

>
> On Tue, Nov 12, 2013 at 4:31 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> Where would the encoding schema be specified?
>>>>
>>>
>>> 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.
>>>
>>
>> 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)
>>
>> 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.
>>
>
> 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.
>

Fair point - it's a worthy goal I had only half considered in this context
but may be worthwhile doing so.

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).

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131112/2f21303f/attachment.html>