search for: ulittle32

...", or would something like "llvm::endian::little" or >> "llvm::le" be more reasonable? > > Llvm has lib/support/endian.h. Wouldn't the new API be redundant? If > not, would it fit in that header? They're obviously related. Endian.h defines types like ulittle32, which DTRT when read and written from memory, whereas clang::io has functions to read and write memory like so: void Emit32(raw_ostream& Out, uint32_t V); uint32_t ReadLE32(const unsigned char *&Data); uint32_t ReadUnalignedLE32(const unsigned char *&Data); The (aligned)...

Rafael Espíndola <rafael.espindola at gmail.com> writes: >> They're obviously related. Endian.h defines types like ulittle32, which >> DTRT when read and written from memory, whereas clang::io has functions >> to read and write memory like so: >> >> void Emit32(raw_ostream& Out, uint32_t V); >> uint32_t ReadLE32(const unsigned char *&Data); >> uint32_t ReadUnaligned...

I would like to use the on disk hash table that's currently in clang for instrumentation based profiling. This is a single header file that's currently found in include/clang/Basic/OnDiskHashTable.h, and I propose to move it to include/llvm/Support/OnDiskHashTable.h. Any strong objections to moving this? Also, the header includes a "clang::io" namespace with some operations for