search for: ondiskhasht

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",...

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

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

...vantage > of already existing, which makes it a pretty good candidate for a > version 1 format, IMHO. > So, I've gone and read all of it to try and get a good handle on the current state rather than dredging up memories from so many years ago. =] I can speak more confidently now. The OnDiskHashTable stuff seems perfectly fine for emitting just that - an on-disk-hash-table. However, it was never designed to support long-lived file formats in that form. The use in serialized ASTs is specifically not supporting a long-term file format. The biggest issue there is endianness, and I see you'...

On Sat, Mar 22, 2014 at 1:18 AM, Justin Bogner <mail at justinbogner.com>wrote: > Chandler Carruth <chandlerc at google.com> writes: > > I think it would be worthwhile to consider the alternative of having > > the profile library write out data files in a format which is > > essentially "always" transformed by a post-processing tool before > >

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

...DebugCounter.h > DotGraphTraits.h > Dwarf.def > Dwarf.h > DynamicLibrary.h > ELF.h > GCOV.h > GenericDomTree.h > GenericDomTreeConstruction.h > GraphWriter.h > LEB128.h > LockFileManager.h > LowLevelTypeImpl.h > MachO.def > MachO.h > MipsABIFlags.h > OnDiskHashTable.h > PluginLoader.h > Registry.h > ScopedPrinter.h > SMLoc.h > Solaris.h > SourceMgr.h > SpecialCaseList.h > TargetParser.h > TargetRegistry.h > TargetSelect.h > TarWriter.h > ToolOutputFile.h > TrigramIndex.h > TypeName.h > Valgrind.h > Wasm.h &gt...

...gt; Dwarf.def > Dwarf.h > DynamicLibrary.h > ELF.h > GCOV.h > GenericDomTree.h > GenericDomTreeConstruction.h > GraphWriter.h > LEB128.h > LEB128.h seems quite generic. > LockFileManager.h > LowLevelTypeImpl.h > MachO.def > MachO.h > MipsABIFlags.h > OnDiskHashTable.h > PluginLoader.h > Registry.h > ScopedPrinter.h > SMLoc.h > Solaris.h > SourceMgr.h > SpecialCaseList.h > TargetParser.h > TargetRegistry.h > TargetSelect.h > TarWriter.h > ToolOutputFile.h > TrigramIndex.h > TypeName.h > Valgrind.h > Wasm.h &gt...

...subclass of Value. [r206255](http://llvm-reviews.chandlerc.com/rL206255). * A DebugInfoVerifier has been implemented. [r206300](http://llvm-reviews.chandlerc.com/rL206300). * MIPS gained initial support for the IEEE 754-2008 NaN encoding. [r206396](http://llvm-reviews.chandlerc.com/rL202812). * OnDiskHashTable has been moved from Clang to LLVM. [r206438](http://llvm-reviews.chandlerc.com/rL206438). * ARM's IR-based atomics pass has been moved from Target to CodeGen, which allows it to be used by ARM64. [r206485](http://llvm-reviews.chandlerc.com/rL206485), [r206490](http://llvm-reviews.chandlerc...

Instrumentation-based profiling data is generated by instrumented binaries through library functions in compiler-rt, and read by the clang frontend to feed PGO. The current data format is a naive textual format. The files consist of a number of counters for each function in a program. Use cases ========= There are a few use cases that drive our requirements: A. Looking up the counters for a