llvm-6502/lib/Support/CMakeLists.txt

115 lines
2.0 KiB
CMake
Raw Normal View History

add_llvm_library(LLVMSupport
APFloat.cpp
APInt.cpp
APSInt.cpp
Allocator.cpp
BlockFrequency.cpp
BranchProbability.cpp
circular_raw_ostream.cpp
CommandLine.cpp
Compression.cpp
ConstantRange.cpp
ConvertUTF.c
ConvertUTFWrapper.cpp
CrashRecoveryContext.cpp
DataExtractor.cpp
DataStream.cpp
Debug.cpp
DeltaAlgorithm.cpp
DAGDeltaAlgorithm.cpp
Dwarf.cpp
ErrorHandling.cpp
FileUtilities.cpp
FileOutputBuffer.cpp
FoldingSet.cpp
FormattedStream.cpp
GraphWriter.cpp
Rewrite LLVM's generalized support library for hashing to follow the API of the proposed standard hashing interfaces (N3333), and to use a modified and tuned version of the CityHash algorithm. Some of the highlights of this change: -- Significantly higher quality hashing algorithm with very well distributed results, and extremely few collisions. Should be close to a checksum for up to 64-bit keys. Very little clustering or clumping of hash codes, to better distribute load on probed hash tables. -- Built-in support for reserved values. -- Simplified API that composes cleanly with other C++ idioms and APIs. -- Better scaling performance as keys grow. This is the fastest algorithm I've found and measured for moderately sized keys (such as show up in some of the uniquing and folding use cases) -- Support for enabling per-execution seeds to prevent table ordering or other artifacts of hashing algorithms to impact the output of LLVM. The seeding would make each run different and highlight these problems during bootstrap. This implementation was tested extensively using the SMHasher test suite, and pased with flying colors, doing better than the original CityHash algorithm even. I've included a unittest, although it is somewhat minimal at the moment. I've also added (or refactored into the proper location) type traits necessary to implement this, and converted users of GeneralHash over. My only immediate concerns with this implementation is the performance of hashing small keys. I've already started working to improve this, and will continue to do so. Currently, the only algorithms faster produce lower quality results, but it is likely there is a better compromise than the current one. Many thanks to Jeffrey Yasskin who did most of the work on the N3333 paper, pair-programmed some of this code, and reviewed much of it. Many thanks also go to Geoff Pike Pike and Jyrki Alakuijala, the original authors of CityHash on which this is heavily based, and Austin Appleby who created MurmurHash and the SMHasher test suite. Also thanks to Nadav, Tobias, Howard, Jay, Nick, Ahmed, and Duncan for all of the review comments! If there are further comments or concerns, please let me know and I'll jump on 'em. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151822 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-01 18:55:25 +00:00
Hashing.cpp
IntEqClasses.cpp
IntervalMap.cpp
IntrusiveRefCntPtr.cpp
IsInf.cpp
IsNAN.cpp
Locale.cpp
LockFileManager.cpp
ManagedStatic.cpp
MemoryBuffer.cpp
MemoryObject.cpp
MD5.cpp
PluginLoader.cpp
PrettyStackTrace.cpp
Regex.cpp
SmallPtrSet.cpp
SmallVector.cpp
SourceMgr.cpp
Statistic.cpp
StreamableMemoryObject.cpp
StringExtras.cpp
StringMap.cpp
StringPool.cpp
StringRef.cpp
MC: Disassembled CFG reconstruction. This patch builds on some existing code to do CFG reconstruction from a disassembled binary: - MCModule represents the binary, and has a list of MCAtoms. - MCAtom represents either disassembled instructions (MCTextAtom), or contiguous data (MCDataAtom), and covers a specific range of addresses. - MCBasicBlock and MCFunction form the reconstructed CFG. An MCBB is backed by an MCTextAtom, and has the usual successors/predecessors. - MCObjectDisassembler creates a module from an ObjectFile using a disassembler. It first builds an atom for each section. It can also construct the CFG, and this splits the text atoms into basic blocks. MCModule and MCAtom were only sketched out; MCFunction and MCBB were implemented under the experimental "-cfg" llvm-objdump -macho option. This cleans them up for further use; llvm-objdump -d -cfg now generates graphviz files for each function found in the binary. In the future, MCObjectDisassembler may be the right place to do "intelligent" disassembly: for example, handling constant islands is just a matter of splitting the atom, using information that may be available in the ObjectFile. Also, better initial atom formation than just using sections is possible using symbols (and things like Mach-O's function_starts load command). This brings two minor regressions in llvm-objdump -macho -cfg: - The printing of a relocation's referenced symbol. - An annotation on loop BBs, i.e., which are their own successor. Relocation printing is replaced by the MCSymbolizer; the basic CFG annotation will be superseded by more related functionality. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182628 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-24 01:07:04 +00:00
StringRefMemoryObject.cpp
SystemUtils.cpp
Timer.cpp
ToolOutputFile.cpp
Triple.cpp
Twine.cpp
YAMLParser.cpp
YAMLTraits.cpp
raw_os_ostream.cpp
raw_ostream.cpp
regcomp.c
regerror.c
regexec.c
regfree.c
regstrlcpy.c
# System
Atomic.cpp
Disassembler.cpp
DynamicLibrary.cpp
Errno.cpp
Host.cpp
IncludeFile.cpp
Memory.cpp
Mutex.cpp
Path.cpp
Process.cpp
Program.cpp
RWMutex.cpp
SearchForAddressOfSpecialSymbol.cpp
Signals.cpp
system_error.cpp
TargetRegistry.cpp
ThreadLocal.cpp
Threading.cpp
TimeValue.cpp
Valgrind.cpp
Watchdog.cpp
Unix/Host.inc
Unix/Memory.inc
Unix/Mutex.inc
Unix/Path.inc
Unix/Process.inc
Unix/Program.inc
Unix/RWMutex.inc
Unix/Signals.inc
Unix/system_error.inc
Unix/ThreadLocal.inc
Unix/TimeValue.inc
Unix/Watchdog.inc
Windows/DynamicLibrary.inc
Windows/Host.inc
Windows/Memory.inc
Windows/Mutex.inc
Windows/Path.inc
Windows/Process.inc
Windows/Program.inc
Windows/RWMutex.inc
Windows/Signals.inc
Windows/system_error.inc
Windows/ThreadLocal.inc
Windows/TimeValue.inc
Windows/Watchdog.inc
)