| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
This also updates the module binaries in the test directory because
their module hash mismatched.
llvm-svn: 248396
|
|
|
|
| |
llvm-svn: 248372
|
|
|
|
| |
llvm-svn: 248353
|
|
|
|
|
|
|
|
| |
debug info.
This does not yet resolve external type references.
llvm-svn: 248331
|
|
|
|
|
|
| |
NFC
llvm-svn: 248312
|
|
|
|
|
|
| |
NFC.
llvm-svn: 248311
|
|
|
|
| |
llvm-svn: 248310
|
|
|
|
|
|
|
| |
Approved by: Rafael Espindola, Eric Christopher, Jim Grosbach,
Alex Rosenberg
llvm-svn: 248302
|
|
|
|
| |
llvm-svn: 248283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction sets like microMIPS.
Summary:
For fixed length instructions, we can use -max_len to limit the fuzzer to a
single instruction. This doesn't work for variable length instruction sets
since a 4-byte input could consist of one 4-byte instruction or two 2-byte
instructions.
This patch adds a --insn-limit to llvm-mc-fuzzer to limit the input in
terms of instructions processed.
Reviewers: kcc
Subscribers: kcc, llvm-commits
Differential Revision: http://reviews.llvm.org/D12960
llvm-svn: 248253
|
|
|
|
|
|
|
|
| |
Otherwise we might end up printing garbage while dumping.
Differential Revision: http://reviews.llvm.org/D13041
llvm-svn: 248239
|
|
|
|
|
|
| |
Patch by Igor Kudrin!
llvm-svn: 248194
|
|
|
|
|
|
| |
extra times. NFC
llvm-svn: 248140
|
|
|
|
| |
llvm-svn: 248096
|
|
|
|
|
|
| |
It seems there's more copy-paste between tools than needed.
llvm-svn: 247954
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r247898 (which reverted r247894).
Patch fixed to address two issues exposed by buildbots:
- unused variable warning in NDEBUG mode
- std::initializer_list lifetime issue causing test failures
Original Summary:
Support for including the function bitcode indices in the Value Symbol
Table. This requires writing the VST after the function blocks, which in
turn requires a new VST forward declaration record encoding the offset of
the full VST (which is backpatched to contain the offset after the VST
is written).
This patch also enables the lazy function reader to use the new function
indices out of the VST. This support will be used by ThinLTO as well, which
will be in a follow on patch. Backwards compatibility with older bitcode
files is maintained.
A new test is also included.
The bitcode format (used for the lazy reader as well as the upcoming
ThinLTO patches) came out of discussions with Duncan and others and is
described here:
https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view
Reviewers: dexonsmith, davidxl, joker.eph
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12536
llvm-svn: 247927
|
|
|
|
|
|
|
|
|
|
| |
Temporarily revert to fix some buildbot issues. One is a minor issue
with a variable unused in NDEBUG mode. More concerning are some test
failures on win7 that I need to dig into.
This reverts commit 4e66a74543459832cfd571db42b4543580ae1d1d.
llvm-svn: 247898
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Support for including the function bitcode indices in the Value Symbol
Table. This requires writing the VST after the function blocks, which in
turn requires a new VST forward declaration record encoding the offset of
the full VST (which is backpatched to contain the offset after the VST
is written).
This patch also enables the lazy function reader to use the new function
indices out of the VST. This support will be used by ThinLTO as well, which
will be in a follow on patch. Backwards compatibility with older bitcode
files is maintained.
A new test is also included.
The bitcode format (used for the lazy reader as well as the upcoming
ThinLTO patches) came out of discussions with Duncan and others and is
described here:
https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view
Reviewers: dexonsmith, davidxl, joker.eph
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12536
llvm-svn: 247894
|
|
|
|
|
|
|
| |
After reading the profile, check if the reader returned any errors
before showing the profile.
llvm-svn: 247873
|
|
|
|
|
|
|
|
| |
gold in NDEBUG mode.
Follow on patch for r247729 - LTO: Disable extra verify runs in release
builds.
llvm-svn: 247824
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Only the disassembler is supported in this patch but it has already found a few
issues in the Mips disassembler (mostly invalid instructions being successfully
disassembled).
Reviewers: kcc
Subscribers: russell.gallop, silvas, kcc, llvm-commits
Differential Revision: http://reviews.llvm.org/D12723
llvm-svn: 247786
|
|
|
|
|
|
|
| |
We already fail with 'No such file or directory' when we try to open
the file -- if that doesn't exist. Also add a test to verify this behavior.
llvm-svn: 247744
|
|
|
|
|
|
|
| |
This reverts commit r247730, effectively reapplying r247729. This time
I have an lld commit ready to follow.
llvm-svn: 247735
|
|
|
|
|
|
|
| |
This temporarily reverts commit r247729, as it caused lld build
failures. I'll recommit once I have an lld patch ready-to-go.
llvm-svn: 247730
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The verifier currently runs three times in LTO: (1) after parsing, (2)
at the beginning of the optimization pipeline, and (3) at the end of it.
The first run is important, since we're not sure where the bitcode comes
from and it's nice to validate it, but in release builds the extra runs
aren't appropriate.
This commit:
- Allows these runs to be disabled in LTOCodeGenerator.
- Adds command-line options to llvm-lto.
- Adds command-line options to libLTO.dylib, and disables the verifier
by default in release builds (based on NDEBUG).
This shaves about 3.5% off the runtime of ld64 when linking
verify-uselistorder with -flto -g.
rdar://22509081
llvm-svn: 247729
|
|
|
|
|
|
|
|
| |
related. NFC.
Eric has replied and has demanded the patch be reverted.
llvm-svn: 247702
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and related. NFC.
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change. Thanks go to Pavel Labath for fixing LLDB for me.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247692
|
|
|
|
|
|
| |
LLDB needs to be updated in the same commit.
llvm-svn: 247686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247683
|
|
|
|
| |
llvm-svn: 247636
|
|
|
|
|
|
|
|
|
|
|
| |
Change the output of llvm-cov s.t it does not truncate function names
and file paths when printing coverage reports.
Differential Revision: http://reviews.llvm.org/D12647
rdar://22531141
llvm-svn: 247635
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change generalizes symlink generation and makes symlinks to tools obey LLVM_TOOLCHAIN_TOOLS. It makes it so that if you exclude llvm-ar from LLVM_TOOLCHAIN_TOOLS you don't end up with broken symlinks to llvm-lib and llvm-ranlib in your install.
Reviewers: bogner, chapuni, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12864
llvm-svn: 247632
|
|
|
|
|
|
| |
This is required because ExternalProject_Add requires all targets specified in the DEPENDS argument must exist before calling ExternalProject_Add.
llvm-svn: 247592
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up to r247518.
As a general note, I think we could do a much better job testing for
error conditions in tools. I already anticipated in a previous mail,
but while implementing this I noticed that the code coverage we have
for error checking is pretty low. I can arbitrarily remove checks from
several tools and the suite still passes.
Differential Revision: http://reviews.llvm.org/D12846
llvm-svn: 247582
|
|
|
|
| |
llvm-svn: 247577
|
|
|
|
|
|
|
|
|
| |
Before we just printed on stderr the program name. Now at least we
print the name of the file that doesn't exist. There's probably room
for improvement of error handling in llvm-mc (and the tools in general),
but still this is a step forward.
llvm-svn: 247518
|
|
|
|
| |
llvm-svn: 247490
|
|
|
|
|
|
|
| |
This is in order to give LTO clients a chance to do some clean-up before
terminating the process.
llvm-svn: 247461
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When cloning the debug info for a function that hasn't been linked,
strip the DIEs from all location attributes that wouldn't contain any
meaningful information anyway.
This kind of situation can happen when a function got discarded by the
linker, but its debug information is still wanted in the final link
because it was marked as required as some other DIE dependency. The easiest
way to get into that situation is to have using directives. They get
linked unconditionally, but their targets might not always be present.
llvm-svn: 247386
|
|
|
|
|
|
|
| |
lldb doesn't like having variables named as an existing type. In order to
ease debugging, rename those variables to avoid that conflict.
llvm-svn: 247385
|
|
|
|
|
|
|
|
| |
This is required because ExternalProject_Add requires all targets specified in the DEPENDS argument must exist before calling ExternalProject_Add.
I have a follow-up patch to clang that enables using the just-built libLTO in bootstrap builds, so we need to be able to add the LTO target as a dependency in clang.
llvm-svn: 247316
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This can be used for distinguishing between cmake and autoconf builds.
Users may need this in order to handle inconsistencies between the
outputs of the two build systems.
Reviewers: echristo, chandlerc, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11838
llvm-svn: 247159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example output:
Linker Options {
Size: 32
Count: 2
Strings [
Value: -framework
Value: Cocoa
]
}
There were only two tests using this -- so I converted them as part of
this commit rather than separately.
Differential Revision: http://reviews.llvm.org/D12702
llvm-svn: 247106
|
|
|
|
| |
llvm-svn: 246976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This diff attempts to address the concerns raised in
http://reviews.llvm.org/D12488.
We introduce a new USE_SHARED option to llvm_config,
which, if set, causes the target to be linked against
libLLVM.
add_llvm_utility now uniformly disables linking against
libLLVM. These utilities are not intended for distribution,
and this keeps the option handling more centralised.
llvm-shlib is now processes before any other "tools"
subdirectories, ensuring the libLLVM target is defined
before its dependents.
One main difference from what was requested: llvm_config
does not prune LLVM_DYLIB_COMPONENTS from the components
passed into explicit_llvm_config. This is because the "all"
component does something special, adding additional
libraries (namely libLTO). Adding the component libraries
after libLLVM should not be a problem, as symbols will be
resolved in libLLVM first.
Finally, I'm not really happy with the
DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a
better way to get the following:
- link all tools and shared libraries to libLLVM if
LLVM_LINK_LLVM_DYLIB is set
- some way of explicitly *not* doing so for utilities
and libLLVM itself
Suggestions for improvement here are particularly welcome.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12590
llvm-svn: 246918
|
|
|
|
|
|
|
| |
This was found while converting a test from macho-dump to llvm-readobj
and will once I commit the converted test.
llvm-svn: 246868
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example output:
File: <stdin>
Format: Mach-O 32-bit i386
Arch: i386
AddressSize: 32bit
Indirect Symbols {
Number: 3
Symbols [
Entry {
Entry Index: 0
Symbol Index: 0x4
}
Entry {
Entry Index: 1
Symbol Index: 0x0
}
Entry {
Entry Index: 2
Symbol Index: 0x1
}
]
}
Differential Revision: http://reviews.llvm.org/D12570
llvm-svn: 246789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add a `cleanupendpad` instruction, used to mark exceptional exits out of
cleanups (for languages/targets that can abort a cleanup with another
exception). The `cleanupendpad` instruction is similar to the `catchendpad`
instruction in that it is an EH pad which is the target of unwind edges in
the handler and which itself has an unwind edge to the next EH action.
The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad`
argument indicating which cleanup it exits. The unwind successors of a
`cleanuppad`'s `cleanupendpad`s must agree with each other and with its
`cleanupret`s.
Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12433
llvm-svn: 246751
|
|
|
|
| |
llvm-svn: 246676
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With a fix for big endian machines. Thanks to Daniel Sanders for the debugging!
Original commit message:
The binaries containing the linked DWARF generated by dsymutil are not
standard relocatable object files like emitted did previsously. They should be
dSYM companion files, which means they have a different file type in the
header, but also a couple other peculiarities:
- they contain the segments and sections from the original binary in their
load commands, but not the actual contents. This means they get an address
and a size, but their offset is always 0 (but these are not virtual sections)
- they also conatin all the defined symbols from the original binary
This makes MC a really bad fit to emit these kind of binaries. The approach
that was used in this patch is to leverage MC's section layout for the
debug sections, but to use a replacement for MachObjectWriter that lives
in MachOUtils.cpp. Some of the low-level helpers from MachObjectWriter
were reused too.
llvm-svn: 246673
|