[PATCH] D31364: LTO: Reduce memory consumption by creating an in-memory symbol table for InputFiles. NFCI.

[Rafael Espíndola via llvm-commits]

> ================
> Comment at: llvm/include/llvm/Object/IRSymtab.h:31
> +
> +typedef support::ulittle32_t Word;
> +
> ----------------
> rafael wrote:
>> why do you use this for Symbol? If we are storing something by value it is better to just use a uint32_t.
> If we eventually want to write these data structures out to files I guess we will need to specify an endianness. The plan I have in mind is:
> 1. define data structures that can be potentially written to files, but use them only as an in-memory format to start with (that is what this patch does)
> 2. potentially improve them in-tree (e.g. by sharing the string table between the module and the symbol table)
> 3. flip the switch and start writing them to files

The two step solution is very reasonable. I see that you currently
write to memory and read back, so it should be easy to write and read
from disk, and yes, we have to specify the endianness for a disk
format. But I think the endianness should be taken care of at the
read/write functions. This is similar to ELF:

* The on disk format has an specific endianness.
* A pointer to a mmap area should use something like support::ulittle32_t*.
* But it should be read once producing a uint32_t.

>From the work on lld I think a reasonable rule of the thumb is then
that the endianness tagged types like support::ulittle32_t should only
be used in pointers.

Cheers,
Rafael