[LLVMdev] [RFC] Moving OnDiskHashTable from clang to LLVM

[Rafael Espíndola]

> A bit more detail on this.
>
> For reading, simply changing the existing clients to use Endian.h is a
> bit of work, as the read functions in clang::io actually move a cursor
> over the read data, so simply switching would actually be something like
> this:
>
>   - unsigned len = ReadUnalignedLE16(Items);
>   + unsigned len = *reinterpret_cast<llvm::support::ulittle16_t *>(Items);
>   + Items += 2;
>
> Presumably, hiding the addition helps maintainability. I suppose we
> could add functions functions that increment the buffer to Endian.h, and
> maybe expose an API like so:
>
>   + unsigned len = support::readFromBuffer<support::ulittle16_t>(Items)
>
>
> For writing, what about adding this to raw_ostream directly? Something
> like:
>
>   template <typename T> raw_ostream &write_le(T V) {
>     for (size_t I = 0, E = sizeof(T); I < E; ++I)
>       *this << (unsigned char)(0xFF & (V >> (I * 8)));
>     return *this;
>   }
>
>   template <typename T> raw_ostream &write_be(T V) {
>     for (size_t I = sizeof(T); I; --I)
>       *this << (unsigned char)(0xFF & (V >> (I * 8)));
>     return *this;
>   }
>
>
> Thoughts?

I think I see your point. The API seem sufficiently different that
there might be use cases where one or the other is better. Using an
explicit increment would make the code less readable. The API in
Endian.h is nice for cases where we know the entire layout of large
data section, since they are composable:

struct dos_header {
  support::ulittle16_t Magic;
  support::ulittle16_t UsedBytesInTheLastPage;
...
};

If the use cases we have in clang or the ones you want to add don't
match this, then regular stream api is probably better. I would keep
it out of raw_ostream, at least for now. How a about a
include/llvm/Support/EndianStream.h?

Cheers,
Rafael