llvm dev - Mar 2014 - [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?

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

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.

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