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
At this time only Unix-based systems are supported. Windows has stubs and should re-route to the simulated mode.
Thanks to Sriram Murali for contributions to this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191843 91177308-0d34-0410-b5e6-96231b3b80d8
infrastructure.
This was essentially work toward PGO based on a design that had several
flaws, partially dating from a time when LLVM had a different
architecture, and with an effort to modernize it abandoned without being
completed. Since then, it has bitrotted for several years further. The
result is nearly unusable, and isn't helping any of the modern PGO
efforts. Instead, it is getting in the way, adding confusion about PGO
in LLVM and distracting everyone with maintenance on essentially dead
code. Removing it paves the way for modern efforts around PGO.
Among other effects, this removes the last of the runtime libraries from
LLVM. Those are being developed in the separate 'compiler-rt' project
now, with somewhat different licensing specifically more approriate for
runtimes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191835 91177308-0d34-0410-b5e6-96231b3b80d8
I really should sort it or do something more sustainable, but I couldn't
work up the energy to do it... Sorry.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191832 91177308-0d34-0410-b5e6-96231b3b80d8
This was broken when options were moved up in r191680. No test because this is
specific LLVMgold.so/libLTO.so.
Patch by Tom Roeder!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191829 91177308-0d34-0410-b5e6-96231b3b80d8
Enable building the LTO library (.lib and.dll) and llvm-lto.exe on Windows with
MSVC and Mingw as well as re-enabling the associated test.
Patch by Greg Bedwell!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191823 91177308-0d34-0410-b5e6-96231b3b80d8
It's useful for the memory managers that are allocating a section to know what the name of the section is.
At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what
memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about
what each allocation is for. This allows clients that supply their own memory managers to do this.
Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM
client.
This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM. I'm assuming that
it's safe to change the C++ API because that API is allowed to change. I'm assuming that it's safe to change
the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory
management C API).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191804 91177308-0d34-0410-b5e6-96231b3b80d8
Tests to follow.
PIC with small code model and EH frame handling will not work with multiple modules. There are also some rough edges to be smoothed out for remote target support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191722 91177308-0d34-0410-b5e6-96231b3b80d8
Enable building the LTO library (.lib and.dll) and llvm-lto.exe on Windows with
MSVC and Mingw as well as re-enabling the associated test.
Patch by Greg Bedwell!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191670 91177308-0d34-0410-b5e6-96231b3b80d8
This is a patch to add capability to llvm-objdump to dump COFF Import Table
entries, so that we can write tests for LLD checking Import Table contents.
llvm-objdump did not print anything but just file name if the format is COFF
and -private-headers option is given. This is a patch adds capability for
dumping DLL Import Table, which is specific to the COFF format.
In this patch I defined a new iterator to iterate over import table entries.
Also added a few functions to COFFObjectFile.cpp to access fields of the entry.
Differential Revision: http://llvm-reviews.chandlerc.com/D1719
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191472 91177308-0d34-0410-b5e6-96231b3b80d8
Various Windows SDK headers use _MSC_VER values to figure out what
version of the VC++ headers they're using, in particular for SAL macros.
Patch by Paul Hampson!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191015 91177308-0d34-0410-b5e6-96231b3b80d8
This puts all the global PassManager debugging flags, like
-print-after-all and -time-passes, behind a managed static. This
eliminates their static initializers and, more importantly, exit-time
destructors.
The only behavioral change I anticipate is that tools need to
initialize the PassManager before parsing the command line in order to
export these options, which makes sense. Tools that already initialize
the standard passes (opt/llc) don't need to do anything new.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190974 91177308-0d34-0410-b5e6-96231b3b80d8
The 'Deprecated' class allows you to specify a SubtargetFeature that the
instruction is deprecated on.
The 'ComplexDeprecationPredicate' class allows you to define a custom
predicate that is called to check for deprecation.
For example:
ComplexDeprecationPredicate<"MCR">
would mean you would have to define the following function:
bool getMCRDeprecationInfo(MCInst &MI, MCSubtargetInfo &STI,
std::string &Info)
Which returns 'false' for not deprecated, and 'true' for deprecated
and store the warning message in 'Info'.
The MCTargetAsmParser constructor was chaned to take an extra argument of
the MCInstrInfo class, so out-of-tree targets will need to be changed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190598 91177308-0d34-0410-b5e6-96231b3b80d8
In DIBuilder, the context field of a TAG_member is updated to use the
scope reference. Verifier is updated accordingly.
DebugInfoFinder now needs to generate a type identifier map to have
access to the actual scope. Same applies for BreakpointPrinter.
processModule of DebugInfoFinder is called during initialization phase
of the verifier to make sure the type identifier map is constructed early
enough.
We are now able to unique a simple class as demonstrated by the added
testing case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190334 91177308-0d34-0410-b5e6-96231b3b80d8
The work on this project was left in an unfinished and inconsistent state.
Hopefully someone will eventually get a chance to implement this feature, but
in the meantime, it is better to put things back the way the were. I have
left support in the bitcode reader to handle the case-range bitcode format,
so that we do not lose bitcode compatibility with the llvm 3.3 release.
This reverts the following commits: 155464, 156374, 156377, 156613, 156704,
156757, 156804 156808, 156985, 157046, 157112, 157183, 157315, 157384, 157575,
157576, 157586, 157612, 157810, 157814, 157815, 157880, 157881, 157882, 157884,
157887, 157901, 158979, 157987, 157989, 158986, 158997, 159076, 159101, 159100,
159200, 159201, 159207, 159527, 159532, 159540, 159583, 159618, 159658, 159659,
159660, 159661, 159703, 159704, 160076, 167356, 172025, 186736
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190328 91177308-0d34-0410-b5e6-96231b3b80d8
We used to generate the compact unwind encoding from the machine
instructions. However, this had the problem that if the user used `-save-temps'
or compiled their hand-written `.s' file (with CFI directives), we wouldn't
generate the compact unwind encoding.
Move the algorithm that generates the compact unwind encoding into the
MCAsmBackend. This way we can generate the encoding whether the code is from a
`.ll' or `.s' file.
<rdar://problem/13623355>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190290 91177308-0d34-0410-b5e6-96231b3b80d8
Iterator of std::vector may be implemented as a raw pointer. In
this case ADL does not find the find() function in the std namespace.
For example, this is the case with STDCXX implementation of vector.
Patch by Konstantin Tokarev.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189733 91177308-0d34-0410-b5e6-96231b3b80d8
Requires shuffling the CPack code up before add_subdirectory(tools), but
that's where the version settings are anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189615 91177308-0d34-0410-b5e6-96231b3b80d8
When unrolling is disabled in the pass manager, the loop vectorizer should also
not unroll loops. This will allow the -fno-unroll-loops option in Clang to
behave as expected (even for vectorizable loops). The loop vectorizer's
-force-vector-unroll option will (continue to) override the pass-manager
setting (including -force-vector-unroll=0 to force use of the internal
auto-selection logic).
In order to test this, I added a flag to opt (-disable-loop-unrolling) to force
disable unrolling through opt (the analog of -fno-unroll-loops in Clang). Also,
this fixes a small bug in opt where the loop vectorizer was enabled only after
the pass manager populated the queue of passes (the global_alias.ll test needed
a slight update to the RUN line as a result of this fix).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189499 91177308-0d34-0410-b5e6-96231b3b80d8
This is just enough to get "llvm-ranlib foo.a" working and tested. Making
llvm-ranlib a symbolic link to llvm-ar doesn't work so well with llvm's option
parsing, but ar's option parsing is mostly custom anyway.
This patch also removes the -X32_64 option. Looks like it was just added in
r10297 as part of implementing the current command line parsing. I can add it
back (with a test) if someone really has AIX portability problems without it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189489 91177308-0d34-0410-b5e6-96231b3b80d8
This allows setting-up the LLVM_EXTERNAL_* CMake variables that some people are using,
e.g. to set the source directory of the project in a different place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189415 91177308-0d34-0410-b5e6-96231b3b80d8
These files are intended to live in the msbuild toolset directory, which
is somewhere like:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
v4.0\Platforms\Win32\PlatformToolsets\llvm
More work is needed to install them as part of the NSIS installer.
Patch by Warren Hunt!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189411 91177308-0d34-0410-b5e6-96231b3b80d8
----
Add new API lto_codegen_compile_parallel().
This API is proposed by Nick Kledzik. The semantic is:
--------------------------------------------------------------------------
Generate code for merged module into an array of native object files. On
success returns a pointer to an array of NativeObjectFile. The count
parameter returns the number of elements in the array. Each element is
a pointer/length for a generated mach-o/ELF buffer. The buffer is owned
by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called,
or lto_codegen_compile() is called again. On failure, returns NULL
(check lto_get_error_message() for details).
extern const struct NativeObjectFile*
lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count);
---------------------------------------------------------------------------
This API is currently only called on OSX platform. Linux or other Unixes
using GNU gold are not supposed to call this function, because on these systems,
object files are fed back to linker via disk file instead of memory buffer.
In this commit, lto_codegen_compile_parallel() simply calls
lto_codegen_compile() to return a single object file. In the near future,
this function is the entry point for compilation with partition. Linker can
blindly call this function even if partition is turned off; in this case,
compiler will return only one object file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189386 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189321 91177308-0d34-0410-b5e6-96231b3b80d8
This API is proposed by Nick Kledzik. The semantic is:
--------------------------------------------------------------------------
Generate code for merged module into an array of native object files. On
success returns a pointer to an array of NativeObjectFile. The count
parameter returns the number of elements in the array. Each element is
a pointer/length for a generated mach-o/ELF buffer. The buffer is owned
by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called,
or lto_codegen_compile() is called again. On failure, returns NULL
(check lto_get_error_message() for details).
extern const struct NativeObjectFile*
lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count);
---------------------------------------------------------------------------
This API is currently only called on OSX platform. Linux or other Unixes
using GNU gold are not supposed to call this function, because on these systems,
object files are fed back to linker via disk file instead of memory buffer.
In this commit, lto_codegen_compile_parallel() simply calls
lto_codegen_compile() to return a single object file. In the near future,
this function is the entry point for compilation with partition. Linker can
blindly call this function even if partition is turned off; in this case,
compiler will return only one object file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189297 91177308-0d34-0410-b5e6-96231b3b80d8
It was previously not being built on Windows because the cmake file relied
on a sed script to generate a .in file that llvm-config needs.
By using cmake's configure_file function, we can get rid off the sed hack,
and also have this work on Windows.
Differential Revision: http://llvm-reviews.chandlerc.com/D1481
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189125 91177308-0d34-0410-b5e6-96231b3b80d8
Allow CMake to pick up external projects in llvm/tools without the need to modify the "llvm/tools/CMakeLists.txt" file.
This makes it easier to work with projects that live in other repositories, without needing to specify each one in "llvm/tools/CMakeLists.txt".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188921 91177308-0d34-0410-b5e6-96231b3b80d8
Like yaml ObjectFiles, this will be very useful for testing the MC CFG
implementation (mostly MCObjectDisassembler), by matching the output
with YAML, and for potential users of the MC CFG, by using it as an input.
There isn't much to the actual format, it is just a serialization of the
MCModule class. Of note:
- Basic block references (pred/succ, ..) are represented by the BB's
start address.
- Just as in the MC CFG, instructions are MCInsts with a size.
- Operands have a prefix representing the type (only register and
immediate supported here).
- Instruction opcodes are represented by their names; enum values aren't
stable, enum names mostly are: usually, a change to a name would need
lots of changes in the backend anyway.
Same with registers.
All in all, an example is better than 1000 words, here goes:
A simple binary:
Disassembly of section __TEXT,__text:
_main:
100000f9c: 48 8b 46 08 movq 8(%rsi), %rax
100000fa0: 0f be 00 movsbl (%rax), %eax
100000fa3: 3b 04 25 48 00 00 00 cmpl 72, %eax
100000faa: 0f 8c 07 00 00 00 jl 7 <.Lend>
100000fb0: 2b 04 25 48 00 00 00 subl 72, %eax
.Lend:
100000fb7: c3 ret
And the (pretty verbose) generated YAML:
---
Atoms:
- StartAddress: 0x0000000100000F9C
Size: 20
Type: Text
Content:
- Inst: MOV64rm
Size: 4
Ops: [ RRAX, RRSI, I1, R, I8, R ]
- Inst: MOVSX32rm8
Size: 3
Ops: [ REAX, RRAX, I1, R, I0, R ]
- Inst: CMP32rm
Size: 7
Ops: [ REAX, R, I1, R, I72, R ]
- Inst: JL_4
Size: 6
Ops: [ I7 ]
- StartAddress: 0x0000000100000FB0
Size: 7
Type: Text
Content:
- Inst: SUB32rm
Size: 7
Ops: [ REAX, REAX, R, I1, R, I72, R ]
- StartAddress: 0x0000000100000FB7
Size: 1
Type: Text
Content:
- Inst: RET
Size: 1
Ops: [ ]
Functions:
- Name: __text
BasicBlocks:
- Address: 0x0000000100000F9C
Preds: [ ]
Succs: [ 0x0000000100000FB7, 0x0000000100000FB0 ]
<snip>
...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188890 91177308-0d34-0410-b5e6-96231b3b80d8
In order to appease people (in Apple) who accuse me for committing "huge change" (?) without proper review.
Thank Eric for fixing a compile-warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188204 91177308-0d34-0410-b5e6-96231b3b80d8
1. Add some helper classes for partitions. They are designed in a
way such that the top-level LTO driver will not see much difference
with or without partitioning.
2. Introduce work-dir. Now all intermediate files generated during
LTO phases will be saved under work-dir. User can specify the workdir
via -lto-workdir=/path/to/dir. By default the work-dir will be
erased before linker exit. To keep the workdir, do -lto-keep, or -lto-keep=1.
TODO: Erase the workdir, if the linker exit prematurely.
We are currently not able to remove directory on signal. The support
routines simply ignore directory.
3. Add one new API lto_codegen_get_files_need_remove().
Linker and LTO plugin will communicate via this API about which files
(including directories) need to removed before linker exit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188188 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, when an invalid attribute is encountered on processing a .s file,
clang will abort due to llvm_unreachable. Invalid user input should not cause
an abnormal termination of the compiler. Change the interface to return a
boolean to indicate the failure as a first step towards improving hanlding of
malformed user input to clang.
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188047 91177308-0d34-0410-b5e6-96231b3b80d8
* ELFTypes.h contains template magic for defining types based on endianess, size, and alignment.
* ELFFile.h defines the ELFFile class which provides low level ELF specific access.
* ELFObjectFile.h contains ELFObjectFile which uses ELFFile to implement the ObjectFile interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188022 91177308-0d34-0410-b5e6-96231b3b80d8
As of this revision, all functions of LTOCodeGenerator are consistent in
ret-true-on-succ.
Tested on multiple OSes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187864 91177308-0d34-0410-b5e6-96231b3b80d8
The ExtractLoops function tries to reduce the failing test case by extracting
one or more loops from the misoptimized piece of the program. In doing this,
ExtractLoops must keep the MiscompiledFunctions vector up-to-date by ensuring
that the pointers refer to functions in the current failing program.
Unfortunately, this is not trivial because:
- ExtractLoops is iterative, and there are several early exits (and the
MiscompiledFunctions vector must be consistent with the current program at
every non-fatal exit point).
- Several of the utility functions used by ExtractLoops (such as
TestOptimizer, some of which are called through the TestFn callback
parameter, and Linker::LinkModules) delete their inputs upon success.
This change adds several updates of the MiscompiledFunctions vector at
different points. The first is after the initial call to TestMergedProgram
which checks that the loop-extracted program still works. The second is after
the call to TestFn (TestOptimizer, for example). This function will delete its
inputs (which is why the existing ExtractLoops logic cloned the inputs first).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187674 91177308-0d34-0410-b5e6-96231b3b80d8
Function attributes are the future! So just query whether we want to realign the
stack directly from the function instead of through a random target options
structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187618 91177308-0d34-0410-b5e6-96231b3b80d8
If no other operation is specified, 's' becomes an operation instead of an
modifier. The s operation just creates a symbol table. It is the same as
running ranlib.
We assume the archive was created by a sane ar (like llvm-ar or gnu ar) and
if the symbol table is present, then it is current. We use that to optimize
the most common case: a broken build system that thinks it has to run ranlib.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187353 91177308-0d34-0410-b5e6-96231b3b80d8
Merge consecutive if-regions if they contain identical statements.
Both transformations reduce number of branches. The transformation
is guarded by a target-hook, and is currently enabled only for +R600,
but the correctness has been tested on X86 target using a variety of
CPU benchmarks.
Patch by: Mei Ye
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187278 91177308-0d34-0410-b5e6-96231b3b80d8
There's no need to specify a flag to omit frame pointer elimination on non-leaf
nodes...(Honestly, I can't parse that option out.) Use the function attribute
stuff instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187093 91177308-0d34-0410-b5e6-96231b3b80d8
The main observation is that we never need both the filesize and the map size.
When mapping a slice of a file, it doesn't make sense to request a null
terminator and that would be the only case where the filesize would be used.
There are other cleanups that should be done in this area:
* A client should not have to pass the size (even an explicit -1) to say if
it wants a null terminator or not, so we should probably swap the argument
order.
* The default should be to not require a null terminator. Very few clients
require this, but many end up asking for it just because it is the default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186984 91177308-0d34-0410-b5e6-96231b3b80d8
The gold plugin was passing the desired map size as the file size. This was
working for two reasons:
* Recent version of gold provide the get_view callback, so this code was not
used.
* In older versions, getOpenFile was called, but the file size is never used
if we don't require null terminated buffers and map size defaults to the
file size.
Thanks to Eli Bendersky for noticing this.
I will try to make this api a bit less error prone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186978 91177308-0d34-0410-b5e6-96231b3b80d8
The symbol table has forward references in the file. Instead of allocating
a temporary buffer or counting the size and then writing, this implementation
writes a dummy value first and patches it once the final value is known.
There is room for performance improvement. I will implement them as soon as I
get some other features (like a ranlib mode) in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186934 91177308-0d34-0410-b5e6-96231b3b80d8
Use the function attributes to pass along the stack protector buffer size.
Now that we have robust function attributes, don't use a command line option to
specify the stack protecto buffer size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186863 91177308-0d34-0410-b5e6-96231b3b80d8
There already have two "dead" functions, initialize{IPO|IPA}, defined for
similar purpose. I decide not to call these two functions for two reasons:
o. they don't cover all LTO passes (which will soon be separated into IPO
and post-IPO passes)
o. We have not yet figured out the right passes and the ordering for IPO
and post-IPO stages, meaning this change is only for the time being.
Since LTO passes are registered, we are now able to print IR before and
after particular point.
For OSX users:
--------------
"...-Wl,-mllvm -Wl,-print-after=<pass-name>" will print IR after the
specified pass.
For Other UNIX with GNU gold linker:
------------------------------------
"-Wl,-plugin-opt=-print-after=<pass-name>" should work.
(NOTE: no need for "-Wl,-mllvm")
Strip "-Wl," if flags are fed directly to linker instead of clang/clang++.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186853 91177308-0d34-0410-b5e6-96231b3b80d8
This matches gnu archive behavior and since archive member order can change
which member is used, not changing the order on replacement looks like the
right thing to do.
This patch also refactors the logic for which archive member to keep and
whether to move it to a helper function (computeInsertAction). The
nesting in computeNewArchiveMembers was getting a bit confusing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186829 91177308-0d34-0410-b5e6-96231b3b80d8
We were incorrectly computing where to insert a member if it was replacing
a previous member that was before the insert point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186792 91177308-0d34-0410-b5e6-96231b3b80d8
The original change was rolled back in r186627 because of test
failures on the big endian machine. I believe I fixed the issue
so re-submitting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186734 91177308-0d34-0410-b5e6-96231b3b80d8
This allows "llvm-mc -disassemble" to accept two new features:
+ Using comma as a byte separator
+ Grouping bytes with '[' and ']' pairs.
The behaviour outside a [...] group is unchanged. But within the group once
llvm-mc encounters a true error, it stops rather than trying to resynchronise
the stream at the next byte. This is more useful for disassembly tests, where
we have an almost-instruction in mind and don't care what the misaligned
interpretation would be. Particularly if it means llvm-mc won't actually see
the next intended almost-instruction.
As a side effect, this means llvm-mc can disassemble its own -show-encoding
output if copy-pasted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186661 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Dump optional data directory entries in the PE/COFF header, so that
we can test the output of LLD linker. This patch updates the test binary
file, but the source of the binary is the same. I just re-linked the file.
I don't know how the previous file was linked, but the previous file did
not have any data directory entries for some reason.
Reviewers: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1148
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186623 91177308-0d34-0410-b5e6-96231b3b80d8
This centralizes the handling of O_BINARY and opens the way for hiding more
differences (like how open behaves with directories).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186447 91177308-0d34-0410-b5e6-96231b3b80d8
This is a micro optimization. Instead of going char*->StringRef->Twine->char*,
go char*->Twine->char* and avoid having to copy the filename on the stack.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186380 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we have robust function attributes, don't use a command line option to
specify the stack protecto buffer size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186217 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes two bugs is lib/Object that the use in llvm-ar found:
* In OS X created archives, the name can be padded with nulls. Strip them.
* In the constructor, remember the first non special member and use that in
begin_children. This makes sure we skip all special members, not just the
first one.
The change to llvm-ar itself consist of
* Using lib/Object for reading archives instead of ArchiveReader.cpp.
* Writing the modified archive directly, instead of creating an in memory
representation.
The old Archive library was way more general than what is needed, as can
be seen by the diffstat of this patch.
Having llvm-ar using lib/Object now opens the way for creating regular symbol
tables for both native objects and bitcode files so that we can use those
archives for LTO.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186197 91177308-0d34-0410-b5e6-96231b3b80d8
* All systems we support have some form of long name support.
* The options has different names and semantics in different implementations
('f' on gnu, 'T' on OS X), which makes it unlikely it is normally used on
build systems.
* It was completely untested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186078 91177308-0d34-0410-b5e6-96231b3b80d8
The problem with running internalize before we're ready to output an object file
is that it may change a 'weak' symbol into an internal one, but that symbol
could be needed by an external object file --- e.g. with arclite.
<rdar://problem/14334895>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185882 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a regression introduced by r185726: the new call to get
a unique file does not prepend the system temporary directory, so
we need to anchor on the file that the temporary file gets moved
to to ensure we're on the same file system.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185825 91177308-0d34-0410-b5e6-96231b3b80d8
