- This code is dead, and the "right" way to get this support is to use the
platform-specific linker-integrated LTO mechanisms, or the forthcoming LLVM
linker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172749 91177308-0d34-0410-b5e6-96231b3b80d8
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
It happens (for example) when you want to have a dependency on the .so
with the specific version, like liblzma.so.1.0.0 or
libcrypto.so.0.9.8.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140201 91177308-0d34-0410-b5e6-96231b3b80d8
forcing them down into various .cpp files.
This change also:
1. Renames TimeValue::toString() and Path::toString() to ::str()
for similarity with the STL.
2. Removes all stream insertion support for sys::Path, forcing
clients to call .str().
3. Removes a use of Config/alloca.h from bugpoint, using smallvector
instead.
4. Weans llvm-db off <iostream>
sys::Path really needs to be gutted, but I don't have the desire to
do it at this point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79869 91177308-0d34-0410-b5e6-96231b3b80d8
of the bitcode reader and ASM parser APIs, as well as supporting it in all of the tools.
Patches for Clang and LLVM-GCC to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74614 91177308-0d34-0410-b5e6-96231b3b80d8
start of a filename, not a filename+length. All clients can produce a
null terminated name, and the system api's require null terminated
strings anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49041 91177308-0d34-0410-b5e6-96231b3b80d8
api's look like this:
ModuleProvider *getBytecodeModuleProvider(
const std::string &Filename, ///< Name of file to be read
BCDecompressor_t *BCDC = Compressor::decompressToNewBuffer,
std::string* ErrMsg = 0, ///< Optional error message holder
BytecodeHandler* H = 0 ///< Optional handler for reader events
);
This is ugly, but allows a client to say:
getBytecodeModuleProvider("foo", 0);
If they do this, there is no dependency on the compression libraries, saving
codesize.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34012 91177308-0d34-0410-b5e6-96231b3b80d8
the module being constructed. This is used to correctly name the module.
Previously the name of the linker tool was used which produces confusing
output when the module identifier is used in an error message.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24699 91177308-0d34-0410-b5e6-96231b3b80d8
Get rid of the difference between file paths and directory paths. The Path
class now simply stores a path that can refer to either a file or a
directory. This required various changes in the implementation and interface
of the class with the corresponding impact to its users. Doxygen comments were
also updated to reflect these changes. Interface changes are:
appendDirectory -> appendComponent
appendFile -> appendComponent
elideDirectory -> eraseComponent
elideFile -> eraseComponent
elideSuffix -> eraseSuffix
renameFile -> rename
setDirectory -> set
setFile -> set
Changes pass Dejagnu and llvm-test/SingleSource tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22349 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix loop style per standards
* Don't create a new Module when the Linker's module is released.
* Add/fix function comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@18871 91177308-0d34-0410-b5e6-96231b3b80d8
