| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
llvm-ar is the only tool that needs to write archive files. Every other tool
should be able to use the lib/Object interface.
llvm-svn: 184083
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Archive files (.a) can have a symbol table indicating which object
files in them define which symbols. The purpose of this symbol table
is to speed up linking by allowing the linker the read only the .o
files it is actually going to use instead of having to parse every
object's symbol table.
LLVM's archive library currently supports a LLVM specific format for
such table. It is hard to see any value in that now that llvm-ld is
gone:
* System linkers don't use it: GNU ar uses the same plugin as the
linker to create archive files with a regular index. The OS X ar
creates no symbol table for IL files, I assume the linker just parses
all IL files.
* It doesn't interact well with archives having both IL and native objects.
* We probably don't want to be responsible for yet another archive
format variant.
This patch then:
* Removes support for creating and reading such index from lib/Archive.
* Remove llvm-ranlib, since there is nothing left for it to do.
We should in the future add support for regular indexes to llvm-ar for
both native and IL objects. When we do that, llvm-ranlib should be
reimplemented as a symlink to llvm-ar, as it is equivalent to "ar s".
llvm-svn: 184019
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 183754
|
|
|
|
| |
llvm-svn: 183669
|
|
|
|
| |
llvm-svn: 176123
|
|
|
|
| |
llvm-svn: 176117
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 171366
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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. =]
llvm-svn: 169131
|
|
|
|
|
|
| |
ArchiveMemberHeader. Found by gcc48 -Wcast-qual.
llvm-svn: 163255
|
|
|
|
|
|
| |
switched from a bytecode+bzip2 to the current bitcode.
llvm-svn: 161651
|
|
|
|
|
|
| |
through StringExtras.h
llvm-svn: 153328
|
|
|
|
| |
llvm-svn: 148681
|
|
|
|
|
|
| |
modules. Avoid that to make the order the linker sees the modules deterministic.
llvm-svn: 148676
|
|
|
|
| |
llvm-svn: 102297
|
|
|
|
| |
llvm-svn: 101783
|
|
|
|
| |
llvm-svn: 101779
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Attached patch removes the extra NUL bytes from the output and changes
test/Archive/MacOSX.toc from a binary to a text file (removes
svn:mime-type=application/octet-stream and adds svn:eol-style=native). I can't
figure out how to get SVN to include the new contents of the file in the patch
so I'm attaching it separately."
Patch by James Abbatiello!
llvm-svn: 95292
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.
Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods. The bindings to
other languages still use the ModuleProvider concept. It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.
Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
llvm-svn: 94686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 79869
|
|
|
|
|
|
|
|
| |
the last time, for the
moment, that I will need to make far-reaching changes.
llvm-svn: 74655
|
|
|
|
| |
llvm-svn: 74640
|
|
|
|
|
|
|
|
|
|
| |
LLVMContext through a lot
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.
llvm-svn: 74614
|
|
|
|
| |
llvm-svn: 61715
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a new ilist_node class, and remove them. Unlike alist_node,
ilist_node doesn't attempt to manage storage itself, so it avoids
the associated problems, including being opaque in gdb.
Adjust the Recycler class so that it doesn't depend on alist_node.
Also, change it to use explicit Size and Align parameters, allowing
it to work when the largest-sized node doesn't have the greatest
alignment requirement.
Change MachineInstr's MachineMemOperand list from a pool-backed
alist to a std::list for now.
llvm-svn: 54146
|
|
|
|
|
|
|
| |
several things that were neither in an anonymous namespace nor static
but not intended to be global.
llvm-svn: 51017
|
|
|
|
|
|
|
| |
MemoryBuffer is higher level and more closely matches the model
needed.
llvm-svn: 49029
|
|
|
|
| |
llvm-svn: 49020
|
|
|
|
| |
llvm-svn: 46514
|
|
|
|
| |
llvm-svn: 45418
|
|
|
|
| |
llvm-svn: 37950
|
|
|
|
|
|
|
| |
files.
bitcode files are the only LLVM format left.
llvm-svn: 37945
|
|
|
|
|
|
| |
Almost all occurrences of "bytecode" in the sources have been eliminated.
llvm-svn: 37913
|
|
llvm-svn: 36886
|