| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
'const' from some other ArrayRef uses since its implicitly const already.
llvm-svn: 216524
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.
For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.
Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.
llvm-svn: 216488
|
|
|
|
|
|
|
| |
Just call parseBitcodeFile instead of getLazyBitcodeModule followed by
materializeAllPermanently.
llvm-svn: 216461
|
|
|
|
|
|
|
|
|
|
| |
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too
big.
llvm-svn: 216393
|
|
|
|
|
|
|
| |
This will avoid code duplication in the next commit which calls it directly
from the gold plugin.
llvm-svn: 216211
|
|
|
|
| |
llvm-svn: 216203
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 216178
|
|
|
|
| |
llvm-svn: 216174
|
|
|
|
|
|
| |
needing to mention the size.
llvm-svn: 216158
|
|
|
|
| |
llvm-svn: 216068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.
Keeping this ownership would make supporting IR inside native objects
particularly painful.
This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.
This patch introduces a few new types.
* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
for convenience functions that take a filename and return both the
buffer and the Binary using that buffer.
The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.
llvm-svn: 216002
|
|
|
|
|
|
|
|
| |
avoid needing to mention the size."
Getting a weird buildbot failure that I need to investigate.
llvm-svn: 215870
|
|
|
|
|
|
| |
needing to mention the size.
llvm-svn: 215868
|
|
|
|
| |
llvm-svn: 215858
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mostly a cleanup, but it changes a fairly old behavior.
Every "real" LTO user was already disabling the silly internalize pass
and creating the internalize pass itself. The difference with this
patch is for "opt -std-link-opts" and the C api.
Now to get a usable behavior out of opt one doesn't need the funny
looking command line:
opt -internalize -disable-internalize -internalize-public-api-list=foo,bar -std-link-opts
llvm-svn: 214919
|
|
|
|
|
|
| |
information and update all callers. No functional change.
llvm-svn: 214781
|
|
|
|
|
|
|
| |
It looks like only direct (i.e., explicitly listed) dependencies are
scanned.
llvm-svn: 214361
|
|
|
|
| |
llvm-svn: 214328
|
|
|
|
| |
llvm-svn: 214312
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and
invites bugs where only one is checked. In reality, the only legitimate
difference between the two (arm64 usually means iOS) is also present in the OS
part of the triple and that's what should be checked.
We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so
there aren't any LLVM-side test changes.
llvm-svn: 213743
|
|
|
|
|
|
|
|
|
|
|
| |
Merges equivalent loads on both sides of a hammock/diamond
and hoists into into the header.
Merges equivalent stores on both sides of a hammock/diamond
and sinks it to the footer.
Can enable if conversion and tolerate better load misses
and store operand latencies.
llvm-svn: 213396
|
|
|
|
|
|
| |
I checked this with Release+Asserts on x86_64-mingw32. Please restore partially if this were overkill.
llvm-svn: 213064
|
|
|
|
| |
llvm-svn: 212405
|
|
|
|
|
|
|
|
|
| |
This reverts commit r212342.
We can get a StringRef into the current Record, but not one in the bitcode
itself since the string is compressed in it.
llvm-svn: 212356
|
|
|
|
|
|
|
|
|
|
| |
These are the llvm.* globals and functions.
I don't think it is possible to test this directly since llvm-lto is not
a full linker and will not report duplicated symbols, but this fixes
bootstrap with gold and lto enabled.
llvm-svn: 212354
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IRObjectFile provides all the logic for producing mangled names and getting
symbols from inline assembly.
LTOModule then adds logic for linking specific tasks, like constructing
llvm.compiler_user or extracting linker options from the bitcode.
The rule of the thumb is that IRObjectFile has the functionality that is
needed by both LTO and llvm-ar.
llvm-svn: 212349
|
|
|
|
| |
llvm-svn: 212348
|
|
|
|
| |
llvm-svn: 212342
|
|
|
|
| |
llvm-svn: 212310
|
|
|
|
|
|
|
|
|
| |
We want to encourage users of the C++ LTO API to reuse memory buffers instead
of repeatedly opening and reading the same file contents.
This reverts commit r212305 and implements a tidier scheme.
llvm-svn: 212308
|
|
|
|
| |
llvm-svn: 212305
|
|
|
|
|
|
|
|
|
| |
This rename makes it easier to identify the specific overload being called
in each particular case and makes future refactorings easier.
Differential Revision: http://reviews.llvm.org/D4370
llvm-svn: 212302
|
|
|
|
| |
llvm-svn: 212299
|
|
|
|
|
|
|
| |
Fixes the build with only the ARM backend enabled. For some reason some
other backend was pulling Object and this went unnoticed.
llvm-svn: 212288
|
|
|
|
|
|
| |
This also enables it in llvm-nm so that it can be tested.
llvm-svn: 212282
|
|
|
|
| |
llvm-svn: 211986
|
|
|
|
|
|
| |
Temporarily back out commits r211749, r211752 and r211754.
llvm-svn: 211814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
string_ostream is a safe and efficient string builder that combines opaque
stack storage with a built-in ostream interface.
small_string_ostream<bytes> additionally permits an explicit stack storage size
other than the default 128 bytes to be provided. Beyond that, storage is
transferred to the heap.
This convenient class can be used in most places an
std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair
would previously have been used, in order to guarantee consistent access
without byte truncation.
The patch also converts much of LLVM to use the new facility. These changes
include several probable bug fixes for truncated output, a programming error
that's no longer possible with the new interface.
llvm-svn: 211749
|
|
|
|
|
|
| |
This completes the refactoring of RecordStreamer.
llvm-svn: 211727
|
|
|
|
|
|
| |
Remove the duplicate from MCRecordStreamer. No functionality change.
llvm-svn: 211714
|
|
|
|
|
|
| |
This saves some duplicated boilerplate in RecordStreamer and NullStreamer.
llvm-svn: 211653
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 211651
|
|
|
|
|
|
|
| |
All the "real" streamers were already calling to MCStreamer::EmitLabel
to do part of the work.
llvm-svn: 211646
|
|
|
|
|
|
|
|
|
|
|
| |
In assembly the expression a=b is parsed as an assignment, so it should be
printed as one.
This remove a truly horrible hack for producing a label with "a=.". It would
be used by codegen but would never be reached by the asm parser. Sorry I
missed this when it was first committed.
llvm-svn: 211639
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 211319
|
|
|
|
|
|
| |
Patch by Tom Roeder, I just added the test.
llvm-svn: 211317
|
|
|
|
| |
llvm-svn: 210871
|
|
|
|
|
|
| |
This should make sure that most new uses use the std prefix.
llvm-svn: 210835
|
|
|
|
|
|
|
| |
This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.
llvm-svn: 210803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was incurring an unsatisfied dependency on CodeGen from LTO breaking
shared builds:
Undefined symbols for architecture x86_64:
"llvm::initializeJumpInstrTablesPass(llvm::PassRegistry&)", referenced from:
llvm::LTOCodeGenerator::initializeLTOPasses() in LTOCodeGenerator.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Removed as a temporary measure pending feedback from the author.
llvm-svn: 210400
|