[llvm-commits] [llvm] r142896 - in /llvm/trunk/test/Bitcode: sse42_crc32.ll sse42_crc32.ll.bc ssse3_palignr.ll ssse3_palignr.ll.bc

Chad Rosier mcrosier at apple.com
Wed Oct 26 10:10:12 PDT 2011


On Oct 25, 2011, at 8:40 PM, Nick Lewycky wrote:

> Chad Rosier wrote:
>> My long term goal is to preserve the Value use-lists ordering across bitcode writing/reading
> 
> Excellent! How?

Great question.  I'm still investigating how this is all going to work, but I'm happy to describe the general direction I would like to pursue.  When the bitcode is emitted by the BitcodeWriter, we know the in-memory ordering of the use-lists we're hoping to preserve.  We also know the order in which the BitcodeReader parses the bitcode file is deterministic (and hopefully rarely changes).  Thus, the BitcodeWriter *should* be able to determine the state of the use-lists that will be restored by the BitcodeReader.  Once we have these two states (i.e., the in-memory state prior to writing and the restored state by the reader), we can generate a diff of sorts.  The BitcodeWriter can then emit the diff into the bitcode, which can then be used by the BitcodeReader to restore the original ordering.  Sounds easy enough, but as Chris said, "the devil's in the details."

This feature has several goals that include: 1) it must not break bitcode compatibility, 2) it must be configurable (i.e., have an on/off switch), 3) when enabled the diffs should be as small as possible so as to not bloat the bitcode files, and 4) when disabled it shouldn't effect the size of the bitcode files.  It goes without say that this enhancement should not effect correctness.

 Chad 

> Nick




More information about the llvm-commits mailing list