| 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
|
|
|
|
| |
llvm-svn: 183947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
switched from a bytecode+bzip2 to the current bitcode.
llvm-svn: 161651
|
|
|
|
| |
llvm-svn: 146523
|
|
|
|
| |
llvm-svn: 126773
|
|
|
|
| |
llvm-svn: 123660
|
|
|
|
|
|
| |
The external API still uses PathV1.""
llvm-svn: 123605
|
|
|
|
|
|
| |
This reverts commit dd103021a889a986a181ce36ed7b0e8dc9b645e1.
llvm-svn: 123595
|
|
|
|
| |
llvm-svn: 123593
|
|
|
|
|
|
| |
external API still uses PathV1."
llvm-svn: 123557
|
|
|
|
|
|
| |
still uses PathV1.
llvm-svn: 123551
|
|
|
|
| |
llvm-svn: 123548
|
|
|
|
| |
llvm-svn: 123152
|
|
|
|
|
|
| |
PathV2::fs::exists.
llvm-svn: 123151
|
|
|
|
|
|
| |
via an out parm.
llvm-svn: 121958
|
|
|
|
|
|
| |
error_code &ec. And fix clients.
llvm-svn: 121379
|
|
|
|
| |
llvm-svn: 120298
|
|
|
|
| |
llvm-svn: 104888
|
|
|
|
| |
llvm-svn: 101783
|
|
|
|
| |
llvm-svn: 99917
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
by cppcheck.
llvm-svn: 73187
|
|
|
|
| |
llvm-svn: 59841
|
|
|
|
|
|
| |
Patch by Mikael Lepistö.
llvm-svn: 51540
|
|
|
|
|
|
|
| |
several things that were neither in an anonymous namespace nor static
but not intended to be global.
llvm-svn: 51017
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 49041
|
|
|
|
|
|
|
| |
MemoryBuffer is higher level and more closely matches the model
needed.
llvm-svn: 49029
|
|
|
|
|
|
|
| |
and shared. This complicates the design, is not used, and probably
doesn't even work.
llvm-svn: 49022
|
|
|
|
| |
llvm-svn: 49020
|
|
|
|
|
|
| |
empty archive. llvm-ar would not generate an output file in this case
llvm-svn: 47733
|
|
|
|
| |
llvm-svn: 47368
|
|
|
|
| |
llvm-svn: 45418
|
|
|
|
|
|
|
| |
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
|