This was originally submitted in r280549, and reverted in r280577
due to breaking one MSVC buildbot. The issue is that MSVC 2013
doesn't synthesize move constructors. So even though i was
writing std::move(A) it was copying it, leading to a bogus ArrayRef.
The solution here is to simply remove the std::vector<> from the
type, since it is unused and unnecessary. This way the ArrayRef
continues to point into the original memory backing the CVType.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280769 91177308-0d34-0410-b5e6-96231b3b80d8
Use the same color for counts and percentages. There doesn't seem to be
a reason for them to be different, and the summary looks more consistent
this way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280765 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a copy of the demangler in libcxxabi.
The code also has no dependencies on anything else in LLVM. To enforce
that I added it as another library. That way a BUILD_SHARED_LIBS will
fail if anyone adds an use of StringRef for example.
The no llvm dependency combined with the fact that this has to build
on linux, OS X and Windows required a few changes to the code. In
particular:
No constexpr.
No alignas
On OS X at least this library has only one global symbol:
__ZN4llvm16itanium_demangleEPKcPcPmPi
My current plan is:
Commit something like this
Change lld to use it
Change lldb to use it as the fallback
Add a few #ifdefs so that exactly the same file can be used in
libcxxabi to export abi::__cxa_demangle.
Once the fast demangler in lldb can handle any names this
implementation can be replaced with it and we will have the one true
demangler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280732 91177308-0d34-0410-b5e6-96231b3b80d8
This replaces the threading of `std::string &Error` through all of
these APIs with checked Error returns instead. There are very few
places here that actually emit any errors right now, but threading the
APIs through will allow us to replace a bunch of exit(1)'s that are
scattered through this code with proper error handling.
This is more or less NFC, but does move around where a couple of error
messages are printed out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280720 91177308-0d34-0410-b5e6-96231b3b80d8
This isn't the right thing to do - it turns out a number of the APIs
that "never fail" just exit(1) if something bad happens. We can and
should thread Error through this instead.
That diff will make more sense with this reverted. Sorry for the
noise.
This reverts r280690
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280691 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies ListReducer and most of its subclasses by removing the
std::string &Error that was threaded through all of them but almost
never used. If we end up needing error handling in more places here we
can reinstate it using llvm::Error instead of these unwieldy strings.
The 2 cases (out of 12) that actually can hit the error cases are a
little bit awkward now, but those will clean up as I refactor this API
further.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280690 91177308-0d34-0410-b5e6-96231b3b80d8
Before we were kind of imitating the behavior of a Yaml sequence
by outputting each record one after the other. This makes it a
little cumbersome when we want to go the other direction -- from
Yaml to Pdb. So this treats FieldList records as no different than
any other list of records, by printing them as a Yaml sequence with
the exact same format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280549 91177308-0d34-0410-b5e6-96231b3b80d8
As discussed in https://reviews.llvm.org/D22666, our current mechanism to
support -pg profiling, where we insert calls to mcount(), or some similar
function, is fundamentally broken. We insert these calls in the frontend, which
means they get duplicated when inlining, and so the accumulated execution
counts for the inlined-into functions are wrong.
Because we don't want the presence of these functions to affect optimizaton,
they should be inserted in the backend. Here's a pass which would do just that.
The knowledge of the name of the counting function lives in the frontend, so
we're passing it here as a function attribute. Clang will be updated to use
this mechanism.
Differential Revision: https://reviews.llvm.org/D22825
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280347 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we were assuming that any visitation of types would
necessarily be against a type we had binary data for. Reasonable
assumption when were just reading PDBs and dumping them, but once
we start writing PDBs from Yaml this breaks down, because we have
no binary data yet, only Yaml, and from that we need to read the
record kind and perform the switch based on that.
So this patch does that. Instead of having the visitor switch
on the kind that is already in the CVType record, we change the
visitTypeBegin() method to return the Kind, and switch on the
returned value. This way, the default implementation can still
return the value from the CVType, but the implementation which
visits Yaml records and serializes binary PDB type records can
use the field in the Yaml as the source of the switch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280307 91177308-0d34-0410-b5e6-96231b3b80d8
We were kind of hacking this together before by embedding the
ability to forward requests into the TypeDeserializer. When
we want to start adding more different kinds of visitor callback
interfaces though, this doesn't scale well and is very inflexible.
So introduce the notion of a pipeline, which itself implements
the TypeVisitorCallbacks interface, but which contains an internal
list of other callbacks to invoke in sequence.
Also update the existing uses of CVTypeVisitor to use this new
pipeline class for deserializing records before visiting them
with another visitor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280293 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 8df7a877949e8782a3a28e3ecdb0770c1e444056.
Fixing other repositories and adding changes together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280152 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for printing the GNU Notes. This allows an easy way to view the
build id for a binary built with the build id. Currently, this only handles the
GNU notes, though it would be easy to extend for other note types (default,
FreeBSD, NetBSD, etc). Only the GNU style is supported currently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280131 91177308-0d34-0410-b5e6-96231b3b80d8
The coverage reports contain the source or binary file paths. On Windows,
the file path might contain the seperators of both '/' and '\'. This patch
uses the native path in the coverage reports. For example, on Windows,
all '/' are converted to '\'.
Differential Revision: https://reviews.llvm.org/D23922
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280061 91177308-0d34-0410-b5e6-96231b3b80d8
switch to using one indirect stub manager per logical dylib rather than one per
input module.
LogicalDylib is a helper class used by the CompileOnDemandLayer to manage
symbol resolution between modules during lazy compilation. In particular, it
ensures that internal symbols resolve correctly even in the case where multiple
input modules contain the same internal symbol name (which must to be promoted
to external hidden linkage so that functions in any given module can be split
out by lazy compilation). LogicalDylib's resolution scheme (before this commit)
required one stub-manager per input module. This made recompilation of functions
(by adding a module containing a new definition) difficult, as the stub manager
for any given symbol was bound to the module that supplied the original
definition. By using one stubs manager for the whole logical dylib symbols can
be more easily replaced, although support for doing this is not included in this
patch (it will be implemented in a follow up).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279952 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Have the cache pass back the path to the cache entry when it
is ready to be loaded, instead of a buffer.
For gold-plugin we can simply pass this file back to gold directly,
which avoids expensive writing of a separate tmp file. Ensure
the cache entry is not deleted on cleanup by adjusting the setting
of the IsTemporary flags.
Moved the loading of the buffer into llvm-lto2 to maintain current
behavior.
Reviewers: mehdi_amini
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D23946
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279883 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
With support now in the new LTO API for caching (r279576), add
optional ThinLTO caching in the gold-plugin.
Reviewers: mehdi_amini
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D23836
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279631 91177308-0d34-0410-b5e6-96231b3b80d8
This patch includes the following changes:
- Included header "Code coverage report" and include the date that the report was created.
- Included title (as specified in a command line option, (i.e llvm-cov -project-title="Simple Test")
- In the summary, list the elf files that the source code file has contributed to.
- Used column heading for "Line No.", "Count No.", Source".
Differential Revision: https://reviews.llvm.org/D23345
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279628 91177308-0d34-0410-b5e6-96231b3b80d8
Re-apply this patch, hopefully I will get away without any warnings
in the constructor now.
This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.
This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.
Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.
Differential Revision: http://reviews.llvm.org/D23736
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279602 91177308-0d34-0410-b5e6-96231b3b80d8
Change this pass constructor to just accept a const TargetMachine * and
use INITIALIZE_TM_PASS, that way we can get rid of the dummy
constructor. The pass will still fail when calling the default
constructor leading to TM == nullptr, this is no different than before
but is more in line what other codegen passes are doing and avoids the
dummy constructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279598 91177308-0d34-0410-b5e6-96231b3b80d8
dereferenced null pointer) in MachineModuleInfo::MachineModuleInfo that causes
-Werror builds (including several buildbots) to fail.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279580 91177308-0d34-0410-b5e6-96231b3b80d8
Add the ability to plug a cache on the LTO API.
I tried to write such that a linker implementation can
control the cache backend. This is intrusive and I'm
not totally happy with it, but I can't figure out a
better design right now.
Differential Revision: https://reviews.llvm.org/D23599
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279576 91177308-0d34-0410-b5e6-96231b3b80d8
Re-apply this commit with the deletion of a MachineFunction delegated to
a separate pass to avoid use after free when doing this directly in
AsmPrinter.
This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.
This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.
Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.
Differential Revision: http://reviews.llvm.org/D23736
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279564 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.
This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.
Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.
Differential Revision: http://reviews.llvm.org/D23736
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279502 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The gold-plugin changes added along with the new LTO API in r278338 had
the effect of removing the management of the PluginInputFile that
ensured the files weren't released back to gold until the backend
threads were complete. Add back the old file handling.
Fixes PR29020.
Reviewers: mehdi_amini
Subscribers: mehdi_amini, llvm-commits, hjl.tools
Differential Revision: https://reviews.llvm.org/D23721
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279356 91177308-0d34-0410-b5e6-96231b3b80d8
The third version component is optional in Xcode's version spew, so we need to make it optional in the regex.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279153 91177308-0d34-0410-b5e6-96231b3b80d8
Xcode 8 requires toolchain compatibility version 2. This allows us to select the correct compatibility version based on the installed version of Xcode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279152 91177308-0d34-0410-b5e6-96231b3b80d8
The original patch was breaking some buildbots due to an
incorrect ordering of function definitions which caused some
compilers to recognize a definition but others to not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279089 91177308-0d34-0410-b5e6-96231b3b80d8
This adds behaviour similar to binutils' objdump which can show symbols in an
import library. Differences from that stem around the fact that we do not
create section symbols nor the all import import descriptor symbol reference.
However, this does mean that the tool can serve as a possible replacement for
the existing tool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279088 91177308-0d34-0410-b5e6-96231b3b80d8
`link -dump -exports` lists exported symbols from import libraries as well as
normal dlls. Ensure that we can handle import libraries as well in
llvm-readobj.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279069 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Skip the merging of common symbols for ThinLTO modules, they will be
merged by the final native object link. Trying to merge the symbols and
add to a combined module will incorrectly enable the common symbol to be
internalized in the ThinLTO module. Additionally, we will not want to
create a combined module for ThinLTO distributed builds.
This fixes failures in 7 cpu2006 benchmarks from the new LTO API in
ThinLTO mode.
Reviewers: mehdi_amini
Subscribers: pcc, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D23637
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279023 91177308-0d34-0410-b5e6-96231b3b80d8
