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

[Chandler Carruth]

On Tue, Nov 12, 2013 at 4:14 PM, Chris Lattner <clattner at apple.com> wrote:

> 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.
>
>
> I guess you could make it work, but would that actually be simpler than
> what is proposed?  If it is denser, how much denser would it have to be to
> justify the complexity?
>

I don't think it would be more complex than a string encoding. At least,
I'm not imagining we want to be super clever here.

I could even imagine doing a versioned giant bitfield and using the version
to handle auto-upgrade...


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


>
> Note that there are simple things that can be done to make MDNodes more
> efficient in common cases.  The CallbackVH is only necessary when pointing
> to Value*’s that are not MDNode/MDString, and
> Constants-other-than-GlobalValue.  If we make MDNode detect when it has
> “all-immortal” operands (like most debug info nodes) then we could just
> store Value*’s directly.  This would be a completely invisible
> implementation improvement, but would not provide the same level of
> improvement as the “flatten into strings” approach.  The two are quite
> complementary.
>

Yea, I'd rather go for at least a bit more dense than that, but maybe we
should do this step-by-step.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131112/f96c779b/attachment.html>