Justin Bogner
2014-Mar-22 08:31 UTC
[LLVMdev] [RFC] Moving OnDiskHashTable from clang to LLVM
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 reading and writing little endian files. Should these be directly renamed to "llvm::io", or would something like "llvm::endian::little" or "llvm::le" be more reasonable?
Rafael Avila de Espindola
2014-Mar-22 15:40 UTC
[LLVMdev] [RFC] Moving OnDiskHashTable from clang to LLVM
Sent from my iPhone> On Mar 22, 2014, at 1:31, Justin Bogner <mail at justinbogner.com> wrote: > > 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 reading and writing little endian files. Should these be directly > renamed to "llvm::io", 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?> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Justin Bogner
2014-Mar-22 20:13 UTC
[LLVMdev] [RFC] Moving OnDiskHashTable from clang to LLVM
Rafael Avila de Espindola <rafael.espindola at gmail.com> writes:>> On Mar 22, 2014, at 1:31, Justin Bogner <mail at justinbogner.com> wrote: >> Also, the header includes a "clang::io" namespace with some operations >> for reading and writing little endian files. Should these be directly >> renamed to "llvm::io", 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) ReadLE32 is easily represented by the stuff in Endian.h, but the write to an ostream and reading unaligned aren't addressed very well at present. We could still add this stuff to Endian.h, assuming it isn't an issue to depend on raw_ostream.h from Endian.h. I'm not sure if that'd be a problem or not.
Jordan Rose
2014-Mar-24 16:34 UTC
[LLVMdev] [cfe-dev] [RFC] Moving OnDiskHashTable from clang to LLVM
I like this idea. I would think that most of the endian-reading functions can be replaced by what's currently in llvm/Support/Endian.h. The writing functions...well, I'm not sure. They're not necessarily going to be useful anywhere else. Jordan On Mar 22, 2014, at 1:31 , Justin Bogner <mail at justinbogner.com> wrote:> 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 reading and writing little endian files. Should these be directly > renamed to "llvm::io", or would something like "llvm::endian::little" or > "llvm::le" be more reasonable? > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev