editbin.exe and link.exe both accepts /highentropyva option to set this bit, so
doing s/VIRTUAL_ADDRESS/VA/ should make sense.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200191 91177308-0d34-0410-b5e6-96231b3b80d8
That bit is not documented in the PE/COFF spec published by Microsoft, so we
don't know the official name of it. I named this bit
IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VIRTUAL_ADDRESS because the bit is
reported as "high entropy virtual address" by dumpbin.exe,
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200121 91177308-0d34-0410-b5e6-96231b3b80d8
PE32+ supports 64 bit address space, but the file format remains 32 bit.
So its file format is pretty similar to PE32 (32 bit executable). The
differences compared to PE32 are (1) the lack of "BaseOfData" field and
(2) some of its data members are 64 bit.
In this patch, I added a new member function to get a PE32+ Header object to
COFFObjectFile class and made llvm-readobj to use it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200117 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a regression introduced by r182908, which broke
llvm-objdump's ability to display relocations inline in a disassembly
dump for ELF object files.
That change removed a SectionRelocMap from Object/ELF.h, which we
recreate in llvm-objdump.cpp.
I discovered this regression via an out-of-tree test
(test/NaCl/X86/pnacl-hides-sandbox-x86-64.ll) which used llvm-objdump.
Note that the "Unknown" string in the test output on i386 isn't quite
right, but this appears to be a pre-existing bug.
Differential Revision: http://llvm-reviews.chandlerc.com/D2559
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200090 91177308-0d34-0410-b5e6-96231b3b80d8
Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200018 91177308-0d34-0410-b5e6-96231b3b80d8
This enables IO error reports in both the child and server processes.
The scheme still isn't entirely satisfactory and output is jumbled but it beats
having no output at all. This will hopefully unblock ARM support (PR18057).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200017 91177308-0d34-0410-b5e6-96231b3b80d8
The client and server now use a single unified low-level RPC core built around
LLVM's existing cross-platform abstractions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199947 91177308-0d34-0410-b5e6-96231b3b80d8
Eliminates the LLI_BUILDING_CHILD build hack from r199885.
Also add a FIXME to remove code that tricks the tests into passing when the
feature fails to work. Please don't do stuff like this, the tests exist for a
reason!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199929 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the target analysis passes (usually TargetTransformInfo) to the
codgen pipeline. We also expose now the AddAnalysisPasses method through the C
API, because the optimizer passes would also benefit from better target-specific
cost models.
Reviewed by Andrew Kaylor
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199926 91177308-0d34-0410-b5e6-96231b3b80d8
Eliminate the copies LLVM's System mmap and cache invalidation code. These were
slowly drifting away from the original version, and moreover the copied code
was a dead end in terms of portability.
We now statically link to Support but in practice with stripping this adds next
to no weight to the resultant binary.
Also avoid installing lli-child-target to the user's $PATH. It's not meant to
be run directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199881 91177308-0d34-0410-b5e6-96231b3b80d8
The execution code path crashes if it can't execute the binary so we might as
well take precautions here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199844 91177308-0d34-0410-b5e6-96231b3b80d8
identify_magic is not free, so we should avoid calling it twice. The argument
also makes it cheap for createBinary to just forward to createObjectFile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199813 91177308-0d34-0410-b5e6-96231b3b80d8
The constructors of classes deriving from Binary normally take an error_code
as an argument to the constructor. My original intent was to change them
to have a trivial constructor and move the initial parsing logic to a static
method returning an ErrorOr. I changed my mind because:
* A constructor with an error_code out parameter is extremely convenient from
the implementation side. We can incrementally construct the object and give
up when we find an error.
* It is very efficient when constructing on the stack or when there is no
error. The only inefficient case is where heap allocating and an error is
found (we have to free the memory).
The result is that this is a much smaller patch. It just standardizes the
create* helpers to return an ErrorOr.
Almost no functionality change: The only difference is that this found that
we were trying to read past the end of COFF import library but ignoring the
error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199770 91177308-0d34-0410-b5e6-96231b3b80d8
Add support to llvm-readobj to decode the actual opcodes. The ARM EHABI opcodes
are a variable length instruction set that describe the operations required for
properly unwinding stack frames.
The primary motivation for this change is to ease the creation of tests for the
ARM EHABI object emission as well as the unwinding directive handling in the ARM
IAS.
Thanks to Logan Chien for an extra test case!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199708 91177308-0d34-0410-b5e6-96231b3b80d8
various opt verifier commandline options.
Mostly mechanical wiring of the verifier to the new pass manager.
Exercises one of the more unusual aspects of it -- a pass can be either
a module or function pass interchangably. If this is ever problematic,
we can make things more constrained, but for things like the verifier
where there is an "obvious" applicability at both levels, it seems
convenient.
This is the next-to-last piece of basic functionality left to make the
opt commandline driving of the new pass manager minimally functional for
testing and further development. There is still a lot to be done there
(notably the factoring into .def files to kill the current boilerplate
code) but it is relatively uninteresting. The only interesting bit left
for minimal functionality is supporting the registration of analyses.
I'm planning on doing that on top of the .def file switch mostly because
the boilerplate for the analyses would be significantly worse.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199646 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the 'verifyFunction' and 'verifyModule' functions totally
independent operations on the LLVM IR. It also cleans up their API a bit
by lifting the abort behavior into their clients and just using an
optional raw_ostream parameter to control printing.
The implementation of the verifier is now just an InstVisitor with no
multiple inheritance. It also is significantly more const-correct, and
hides the const violations internally. The two layers that force us to
break const correctness are building a DomTree and dispatching through
the InstVisitor.
A new VerifierPass is used to implement the legacy pass manager
interface in terms of the other pieces.
The error messages produced may be slightly different now, and we may
have slightly different short circuiting behavior with different usage
models of the verifier, but generally everything works equivalently and
this unblocks wiring the verifier up to the new pass manager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199569 91177308-0d34-0410-b5e6-96231b3b80d8
When registering a pass, a pass can now specify a second construct that takes as
argument a pointer to TargetMachine.
The PassInfo class has been updated to reflect that possibility.
If such a constructor exists opt will use it instead of the default constructor
when instantiating the pass.
Since such IR passes are supposed to be rare, no specific support has been
added to this commit to allow an easy registration of such a pass.
In other words, for such pass, the initialization function has to be
hand-written (see CodeGenPrepare for instance).
Now, codegenprepare can be tested using opt:
opt -codegenprepare -mtriple=mytriple input.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199430 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the capability to dump export table contents. An example
output is this:
Export Table:
Ordinal RVA Name
5 0x2008 exportfn1
6 0x2010 exportfn2
By adding this feature to llvm-objdump, we will be able to use it to check
export table contents in LLD's tests. Currently we are doing binary
comparison in the tests, which is fragile and not readable to humans.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199358 91177308-0d34-0410-b5e6-96231b3b80d8
If a binary does not depend on any DLL, it does not contain import table at
all. Printing the section title without contents looks wrong, so we shouldn't
print it in that case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199340 91177308-0d34-0410-b5e6-96231b3b80d8
Add a hook in the C API of LTO so that clients of the code generator can set
their own handler for the LLVM diagnostics.
The handler is defined like this:
typedef void (*lto_diagnostic_handler_t)(lto_codegen_diagnostic_severity_t
severity, const char *diag, void *ctxt)
- severity says how bad this is.
- diag is a string that contains the diagnostic message.
- ctxt is the registered context for this handler.
This hook is more general than the lto_get_error_message, since this function
keeps only the latest message and can only be queried when something went wrong
(no warning for instance).
<rdar://problem/15517596>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199338 91177308-0d34-0410-b5e6-96231b3b80d8
I did write a version returning ErrorOr<OwningPtr<Binary> >, but it is too
cumbersome to use without std::move. I will keep the patch locally and submit
when we switch to c++11.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199326 91177308-0d34-0410-b5e6-96231b3b80d8
MCJIT remote execution (ChildTarget+RemoteTargetExternal) protocol was in
dire need of refactoring. It was fail-prone, had no error reporting and
implemented the same message logic on every single function.
This patch rectifies it, and makes it work on ARM, where it was randomly
failing. Other architectures shall profit from this change as well, making
their buildbots and releases more reliable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199261 91177308-0d34-0410-b5e6-96231b3b80d8
Reapply r199191, reverted in r199197 because it carelessly broke
Other/link-opts.ll. The problem was that calling
createInternalizePass("main") would select
createInternalizePass(bool("main")) instead of
createInternalizePass(ArrayRef<const char *>("main")). This commit
fixes the bug.
The original commit message follows.
Add API to LTOCodeGenerator to specify a strategy for the -internalize
pass.
This is a new attempt at Bill's change in r185882, which he reverted in
r188029 due to problems with the gold linker. This puts the onus on the
linker to decide whether (and what) to internalize.
In particular, running internalize before outputting an object file may
change a 'weak' symbol into an internal one, even though that symbol
could be needed by an external object file --- e.g., with arclite.
This patch enables three strategies:
- LTO_INTERNALIZE_FULL: the default (and the old behaviour).
- LTO_INTERNALIZE_NONE: skip -internalize.
- LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden
visibility.
LTO_INTERNALIZE_FULL should be used when linking an executable.
Outputting an object file (e.g., via ld -r) is more complicated, and
depends on whether hidden symbols should be internalized. E.g., for
ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and
LTO_INTERNALIZE_HIDDEN can be used otherwise. However,
LTO_INTERNALIZE_FULL is inappropriate, since the output object file will
eventually need to link with others.
lto_codegen_set_internalize_strategy() sets the strategy for subsequent
calls to lto_codegen_write_merged_modules() and lto_codegen_compile*().
<rdar://problem/14334895>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199244 91177308-0d34-0410-b5e6-96231b3b80d8
Newer unix systems have 32 bit uid and gid types, but the archive format was
not updated. Fortunately, these fields are not normally used. Just truncate
the data to fit in 6 chars.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199223 91177308-0d34-0410-b5e6-96231b3b80d8
Add API to LTOCodeGenerator to specify a strategy for the -internalize
pass.
This is a new attempt at Bill's change in r185882, which he reverted in
r188029 due to problems with the gold linker. This puts the onus on the
linker to decide whether (and what) to internalize.
In particular, running internalize before outputting an object file may
change a 'weak' symbol into an internal one, even though that symbol
could be needed by an external object file --- e.g., with arclite.
This patch enables three strategies:
- LTO_INTERNALIZE_FULL: the default (and the old behaviour).
- LTO_INTERNALIZE_NONE: skip -internalize.
- LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden
visibility.
LTO_INTERNALIZE_FULL should be used when linking an executable.
Outputting an object file (e.g., via ld -r) is more complicated, and
depends on whether hidden symbols should be internalized. E.g., for
ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and
LTO_INTERNALIZE_HIDDEN can be used otherwise. However,
LTO_INTERNALIZE_FULL is inappropriate, since the output object file will
eventually need to link with others.
lto_codegen_set_internalize_strategy() sets the strategy for subsequent
calls to lto_codegen_write_merged_modules() and lto_codegen_compile*().
<rdar://problem/14334895>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199191 91177308-0d34-0410-b5e6-96231b3b80d8
can be used by both the new pass manager and the old.
This removes it from any of the virtual mess of the pass interfaces and
lets it derive cleanly from the DominatorTreeBase<> template. In turn,
tons of boilerplate interface can be nuked and it turns into a very
straightforward extension of the base DominatorTree interface.
The old analysis pass is now a simple wrapper. The names and style of
this split should match the split between CallGraph and
CallGraphWrapperPass. All of the users of DominatorTree have been
updated to match using many of the same tricks as with CallGraph. The
goal is that the common type remains the resulting DominatorTree rather
than the pass. This will make subsequent work toward the new pass
manager significantly easier.
Also in numerous places things became cleaner because I switched from
re-running the pass (!!! mid way through some other passes run!!!) to
directly recomputing the domtree.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199104 91177308-0d34-0410-b5e6-96231b3b80d8
directory. These passes are already defined in the IR library, and it
doesn't make any sense to have the headers in Analysis.
Long term, I think there is going to be a much better way to divide
these matters. The dominators code should be fully separated into the
abstract graph algorithm and have that put in Support where it becomes
obvious that evn Clang's CFGBlock's can use it. Then the verifier can
manually construct dominance information from the Support-driven
interface while the Analysis library can provide a pass which both
caches, reconstructs, and supports a nice update API.
But those are very long term, and so I don't want to leave the really
confusing structure until that day arrives.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199082 91177308-0d34-0410-b5e6-96231b3b80d8
This moves the old pass creation functionality to its own header and
updates the callers of that routine. Then it adds a new PM supporting
bitcode writer to the header file, and wires that up in the opt tool.
A test is added that round-trips code into bitcode and back out using
the new pass manager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199078 91177308-0d34-0410-b5e6-96231b3b80d8
that through the interface rather than a simple bool. This should allow
starting to wire up real output to round-trip IR through opt with the
new pass manager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199071 91177308-0d34-0410-b5e6-96231b3b80d8
This implements the legacy passes in terms of the new ones. It adds
basic testing using explicit runs of the passes. Next up will be wiring
the basic output mechanism of opt up when the new pass manager is
engaged unless bitcode writing is requested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8
Nothing was using the ability of the pass to delete the raw_ostream it
printed to, and nothing was trying to pass it a pointer to the
raw_ostream. Also, the function variant had a different order of
arguments from all of the others which was just really confusing. Now
the interface accepts a reference, doesn't offer to delete it, and uses
a consistent order. The implementation of the printing passes haven't
been updated with this simplification, this is just the API switch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199044 91177308-0d34-0410-b5e6-96231b3b80d8
name to match the source file which I got earlier. Update the include
sites. Also modernize the comments in the header to use the more
recommended doxygen style.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199041 91177308-0d34-0410-b5e6-96231b3b80d8
nests to the opt commandline support. This also showcases the
implicit-initial-manager support which will be most useful for testing.
There are several bugs that I spotted by inspection here that I'll fix
with test cases in subsequent commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199038 91177308-0d34-0410-b5e6-96231b3b80d8
mode that can be used to debug the execution of everything.
No support for analyses here, that will come later. This already helps
show parts of the opt commandline integration that isn't working. Tests
of that will start using it as the bugs are fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199004 91177308-0d34-0410-b5e6-96231b3b80d8
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198998 91177308-0d34-0410-b5e6-96231b3b80d8
root path to which object files managed by the LLIObjectCache instance should be
written. This option defaults to "", in which case objects are cached in the
same directory as the bitcode they are derived from.
The load-object-a.ll test has been rewritten to use this option to support
testing in environments where the test directory is not writable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198852 91177308-0d34-0410-b5e6-96231b3b80d8
Rename bytecode to opcodes to make it more clear. Change an impossible case to
llvm_unreachable instead. Avoid allocation of a buffer by modifying the
PrintOpcodes iteration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198848 91177308-0d34-0410-b5e6-96231b3b80d8
operand into the Value interface just like the core print method is.
That gives a more conistent organization to the IR printing interfaces
-- they are all attached to the IR objects themselves. Also, update all
the users.
This removes the 'Writer.h' header which contained only a single function
declaration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198836 91177308-0d34-0410-b5e6-96231b3b80d8
I believe the bot failures on linux systems were due to overestimating the
alignment of object-files within archives, which are only guaranteed to be
two-byte aligned. I have reduced the alignment in
RuntimeDyldELF::createObjectImageFromFile accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198737 91177308-0d34-0410-b5e6-96231b3b80d8
This adds some preliminary support for decoding ARM EHABI unwinding information.
The major functionality that remains from complete support is bytecode
translation.
Each Unwind Index Table is printed out as a separate entity along with its
section index, name, offset, and entries.
Each entry lists the function address, and if possible, the name, of the
function to which it corresponds. The encoding model, personality routine or
index, and byte code is also listed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198734 91177308-0d34-0410-b5e6-96231b3b80d8
are part of the core IR library in order to support dumping and other
basic functionality.
Rename the 'Assembly' include directory to 'AsmParser' to match the
library name and the only functionality left their -- printing has been
in the core IR library for quite some time.
Update all of the #includes to match.
All of this started because I wanted to have the layering in good shape
before I started adding support for printing LLVM IR using the new pass
infrastructure, and commandline support for the new pass infrastructure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198688 91177308-0d34-0410-b5e6-96231b3b80d8
(unittests/ExecutionEngine/JIT/CMakeLists.txt is still missing for now, since
it handles export files in a strange way: It generates a .exports file from a
.def file instead of the other way round.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198183 91177308-0d34-0410-b5e6-96231b3b80d8
The cmake build didn't support EXPORTED_SYMBOL_FILE. Instead, it had a
Windows-only implementation in tools/lto/CMakeLists.txt, a linux-only
implementation in tools/gold/CMakeLists.txt, and a darwin-only implementation
in tools/clang/tools/libclang/CMakeLists.txt.
This attempts to consolidate these one-offs into a single place. Clients can now
just set LLVM_EXPORTED_SYMBOL_FILE and things (hopefully) Just Work, like in
the make build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198136 91177308-0d34-0410-b5e6-96231b3b80d8
This reduces the size of clang-format from 22 MB to 1.8 MB, diagtool goes from
21 MB to 2.8 MB, libclang.so goes from 29 MB to 20 MB, etc. The size of the
bin/ folder shrinks from 270 MB to 200 MB.
Targets that support plugins and don't already use EXPORTED_SYMBOL_FILE
(which libclang and libLTO already do) can set NO_DEAD_STRIP to opt out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198087 91177308-0d34-0410-b5e6-96231b3b80d8
Although --system-libs is expected to use after --libs, it can be used alone.
$ bin/llvm-config --ldflags
-L/path/to/llvm/objroot/lib
$ bin/llvm-config --libs object
-lLLVMObject -lLLVMSupport
$ bin/llvm-config --system-libs
(Blank line. "all" is assumed but nothing is printed.)
-lrt -ldl -ltinfo -lpthread -lz
$ bin/llvm-config --ldflags --libs --system-libs object
-L/path/to/llvm/objroot/lib
-lLLVMObject -lLLVMSupport
-lrt -ldl -ltinfo -lpthread -lz
It is reimplementation of r197380, and workaround for PR3347 and PR8449.
FIXME: Each LLVM component may have its dependent system libs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197664 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to the file summaries, the function summaries output line,
branching and call statistics. The file summaries have been moved
outside the initial loop so that all of the function summaries can be
outputted before file summaries.
Also updated test cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197633 91177308-0d34-0410-b5e6-96231b3b80d8
This will cause llvm-cov to output branch counts instead of branch
probabilities. -b must be enabled.
Also updated tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197594 91177308-0d34-0410-b5e6-96231b3b80d8
With llvm-config.exe --bindir --libdir --build-mode, on Visual Studio 2010,
In build tree:
(OBJ_ROOT)/bin/MinSizeRel
(OBJ_ROOT)/lib/MinSizeRel
MinSizeRel
In installed tree:
(INSTALL_PREFIX)/bin
(INSTALL_PREFIX)/lib
MinSizeRel
This is enhancements since r196283.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197467 91177308-0d34-0410-b5e6-96231b3b80d8
Outputs branch information for unconditional branches in addition to
conditional branches. -b option must be enabled.
Also updated tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197432 91177308-0d34-0410-b5e6-96231b3b80d8
Each of them forms like;
${CMAKE_BINARY_DIR}/bin/${CMAKE_CFG_INTDIR}
${CMAKE_BINARY_DIR}/lib/${CMAKE_CFG_INTDIR}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197394 91177308-0d34-0410-b5e6-96231b3b80d8
FIXME: Host's llvm-config is not generated. It's for target's.
Host tools, aka "BuildTools", in utils, do not require llvm-config to build.
For example with --host=i686-pc-mingw32 --build=linux,
$ BuildTools/Release+Asserts/bin/llvm-config --libs support
-lLLVMSupport
-lpthread -lshell32 -lpsapi -limagehlp -lm
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197382 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM libs are printed in the first line, and system libs are printed in the next line.
$ bin/llvm-config --libs object
-lLLVMObject -lLLVMSupport
-lrt -ldl -ltinfo -lpthread -lz
It is workaround for PR3347 and PR8449.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197380 91177308-0d34-0410-b5e6-96231b3b80d8
This option tells llvm-cov to print out branch probabilities when
a basic block contains multiple branches. It also prints out some
function summary info including the number of times the function enters,
the percent of time it returns, and how many blocks were executed.
Also updated tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197198 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to gcov, llvm-cov will now print out the block count at the end
of each block. Multiple blocks can end on the same line.
One computational difference is by using -a, llvm-cov will no longer
simply add the block counts together to form a line count. Instead, it
will take the maximum of the block counts on that line. This has a
similar effect to what gcov does, but generates more correct counts in
certain scenarios.
Also updated tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196856 91177308-0d34-0410-b5e6-96231b3b80d8
The intended behaviour is to force vectorization on the presence
of the flag (either turn on or off), and to continue the behaviour
as expected in its absence. Tests were added to make sure the all
cases are covered in opt. No tests were added in other tools with
the assumption that they should use the PassManagerBuilder in the
same way.
This patch also removes the outdated -late-vectorize flag, which was
on by default and not helping much.
The pragma metadata is being attached to the same place as other loop
metadata, but nothing forbids one from attaching it to a function
(to enable #pragma optimize) or basic blocks (to hint the basic-block
vectorizers), etc. The logic should be the same all around.
Patches to Clang to produce the metadata will be produced after the
initial implementation is agreed upon and committed. Patches to other
vectorizers (such as SLP and BB) will be added once we're happy with
the pass manager changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196537 91177308-0d34-0410-b5e6-96231b3b80d8
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196471 91177308-0d34-0410-b5e6-96231b3b80d8
This splits the file-scope read() function into readGCNO() and
readGCDA(). Also broke file format read into functions that first read
the file type, then check the version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196353 91177308-0d34-0410-b5e6-96231b3b80d8
clang enables vectorization at optimization levels > 1 and size level < 2. opt
should behave similarily.
Loop vectorization and SLP vectorization can be disabled with the flags
-disable-(loop/slp)-vectorization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196294 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of asking the user to specify a single file to output coverage
info and defaulting to STDOUT, llvm-cov now creates files for each
source file with a naming system of: <source filename> + ".llcov".
This is what gcov does and although it can clutter the working directory
with numerous coverage files, it will be easier to hook the llvm-cov
output to tools which operate on this assumption (such as lcov).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196184 91177308-0d34-0410-b5e6-96231b3b80d8
This file hasn't been updated in years. Remove old information and point to
the current documentation at GoldPlugin.rst.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196100 91177308-0d34-0410-b5e6-96231b3b80d8
only user was an ancient SCC printing bit of the opt tool which really
should be walking the call graph the same way the CGSCC pass manager
does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195800 91177308-0d34-0410-b5e6-96231b3b80d8
CallGraph.
This makes the CallGraph a totally generic analysis object that is the
container for the graph data structure and the primary interface for
querying and manipulating it. The pass logic is separated into its own
class. For compatibility reasons, the pass provides wrapper methods for
most of the methods on CallGraph -- they all just forward.
This will allow the new pass manager infrastructure to provide its own
analysis pass that constructs the same CallGraph object and makes it
available. The idea is that in the new pass manager, the analysis pass's
'run' method returns a concrete analysis 'result'. Here, that result is
a 'CallGraph'. The 'run' method will typically do only minimal work,
deferring much of the work into the implementation of the result object
in order to be lazy about computing things, but when (like DomTree)
there is *some* up-front computation, the analysis does it prior to
handing the result back to the querying pass.
I know some of this is fairly ugly. I'm happy to change it around if
folks can suggest a cleaner interim state, but there is going to be some
amount of unavoidable ugliness during the transition period. The good
thing is that this is very limited and will naturally go away when the
old pass infrastructure goes away. It won't hang around to bother us
later.
Next up is the initial new-PM-style call graph analysis. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195722 91177308-0d34-0410-b5e6-96231b3b80d8
I changed the registry key in that commit, but forgot to update
the integration files. This change makes them use the same variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195479 91177308-0d34-0410-b5e6-96231b3b80d8
This patch places class definitions in implementation files into anonymous
namespaces to prevent weak vtables. This eliminates the need of providing an
out-of-line definition to pin the vtable explicitly to the file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195092 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195064 91177308-0d34-0410-b5e6-96231b3b80d8
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194997 91177308-0d34-0410-b5e6-96231b3b80d8
Linux cannot open directories with open(2), although cygwin and *bsd can.
Motivation: The test, Object/directory.ll, had been failing with --target=cygwin on Linux. XFAIL was improper for host issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194257 91177308-0d34-0410-b5e6-96231b3b80d8
This will allow for much easier testing when the input files are in a
different folder from the test script.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194034 91177308-0d34-0410-b5e6-96231b3b80d8
There are two ways one could implement hiding of linkonce_odr symbols in LTO:
* LLVM tells the linker which symbols can be hidden if not used from native
files.
* The linker tells LLVM which symbols are not used from other object files,
but will be put in the dso symbol table if present.
GOLD's API is the second option. It was implemented almost 1:1 in llvm by
passing the list down to internalize.
LLVM already had partial support for the first option. It is also very similar
to how ld64 handles hiding these symbols when *not* doing LTO.
This patch then
* removes the APIs for the DSO list.
* marks LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN all linkonce_odr unnamed_addr
global values and other linkonce_odr whose address is not used.
* makes the gold plugin responsible for handling the API mismatch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193800 91177308-0d34-0410-b5e6-96231b3b80d8
- Mark tests as XFAIL:cygming in test/ExecutionEngine/MCJIT/remote.
Rather to suppress them, I'd like to leave them running as XFAIL.
- Revert r193472. RecordMemoryManager no longer resolves __main on cygming.
There are a couple of issues.
- X86 Codegen emits "call __main" in @main for targeting cygming.
It is useless in JIT. FYI, tests are passing when emitting __main is disabled.
- Current remote JIT does not resolve any symbols in child context.
FIXME: __main should be disabled, or remote JIT should resolve __main.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193498 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently shared library builds (BUILD_SHARED_LIBS=ON in cmake) fail three
bugpoint tests (BugPoint/remove_arguments_test.ll,
BugPoint/crash-narrowfunctiontest.ll, and BugPoint/metadata.ll).
If I run the bugpoint commands that llvm-lit runs with without -silence-passes
I see errors such as this:
opt: error while loading shared libraries: libLLVMSystemZInfo.so: failed to
map segment from shared object: Cannot allocate memory
It seems that the increased size of the binaries in a shared library build is
causing the subprocess to exceed the 100MB memory limit. This patch therefore
increases the default limit to a level at which these tests pass.
Reviewers: dsanders
Reviewed By: dsanders
CC: llvm-commits, rafael
Differential Revision: http://llvm-reviews.chandlerc.com/D2013
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193420 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r193255 and instead creates an lto_bool_t typedef
that points to bool, _Bool, or unsigned char depending on what is
available. Only recent versions of MSVC provide a stdbool.h header.
Reviewers: rafael.espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D2019
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193377 91177308-0d34-0410-b5e6-96231b3b80d8
This provides rudimentary testing of the llvm-c api.
The following commands are implemented:
* --module-dump
Read bytecode from stdin - print ir
* --module-list-functions
Read bytecode from stdin - list summary of functions
* --module-list-globals
Read bytecode from stdin - list summary of globals
* --targets-list
List available targets
* --object-list-sections
Read object file from stdin - list sections
* --object-list-symbols
Read object file from stdin - list symbols (like nm)
* --disassemble
Read lines of triple, hex ascii machine code from stdin - print disassembly
* --calc
Read lines of name, rpn from stdin - print generated module ir
Differential-Revision: http://llvm-reviews.chandlerc.com/D1776
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193233 91177308-0d34-0410-b5e6-96231b3b80d8
- Replaced tabs with proper padding
- print() takes two arguments, which are the GCNO and GCDA filenames
- Files are listed at the top of output, appended by line 0
- Stripped strings of trailing \0s
- Removed last two lines of whitespace in output
Patch by Yuchen Wu!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193148 91177308-0d34-0410-b5e6-96231b3b80d8
collectLineCounts() should only organize the output data. This is done in
anticipation of subsequent changes which will pass in GCNO and GCDA filenames
into the print function where it is printed similar to the gcov output.
Patch by Yuchen Wu!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193134 91177308-0d34-0410-b5e6-96231b3b80d8
* std::string::append(int, int) can be ambiguous.
* std::vector<>::data() is a C++11 feature, use ArrayRef abstraction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192542 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a problem from a previous check-in where a return value was omitted.
Previously the remote/stubs-remote.ll and remote/stubs-sm-pic.ll tests were reporting passes, but they should have been failing. Those tests attempt to link against an external symbol and remote symbol resolution is not supported. The old RemoteMemoryManager implementation resulted in local symbols being used for resolution and the child process crashed but the test didn't notice. With this check-in remote symbol resolution fails, and so the test (correctly) fails.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192514 91177308-0d34-0410-b5e6-96231b3b80d8
We previously failed to check whether the SUCCESS variable was set,
and would thus always exit with a failure if vs2012 didn't exist.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192370 91177308-0d34-0410-b5e6-96231b3b80d8
r191088 is "llvm/tools/Makefile: Suppress building llvm-lto on cygming, for now, probably due to LTO.dll."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192104 91177308-0d34-0410-b5e6-96231b3b80d8
Generalize the API so we can distinguish symbols that are needed just for a DSO
symbol table from those that are used from some native .o.
The symbols that are only wanted for the dso symbol table can be dropped if
llvm can prove every other dso has a copy (linkonce_odr) and the address is not
important (unnamed_addr).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191922 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it possible to add timers to the code generator and still use them
with -plugin-opt=emit-llvm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191866 91177308-0d34-0410-b5e6-96231b3b80d8
