Introducing llvm-profdata, a tool for merging profile data generated by
PGO instrumentation in clang.

- The name indicates a file extension of <name>.profdata.  Eventually
  profile data output by clang should be changed to that extension.

- llvm-profdata merges two profiles.  However, the name is more general,
  since it will likely pick up more tasks (such as summarizing a single
  profile).

- llvm-profdata parses the current text-based format, but will be
  updated once we settle on a binary format.

<rdar://problem/15949645>

llvm-svn: 201535

It was pointing to lib\clang\3.4, but now we're on 3.5.
Make CMake insert the right version automatically.

llvm-svn: 201363

This does exactly the same thing as for Win32, except it passes -m64 to
the compiler and the files go in a different directory.

Differential Revision: http://llvm-reviews.chandlerc.com/D2749

llvm-svn: 201269

BreakpointPrinter moves to its own module.

llvm-svn: 201242

Thanks to İsmail Dönmez for the better declaration.

llvm-svn: 201163

use the hardcoded declaration 3
See r201110 for the initial change

llvm-svn: 201161

These are self-contained in functionality so it makes sense to separate them,
as opt.cpp has grown quite big already.

Following Eric's suggestions, if this code is ever deemed useful outside of
tools/opt, it will make sense to move it to one of the LLVM libraries like IR.

llvm-svn: 201116

This function adds an extra path argument to lto_module_create_from_memory.
The path argument will be passed to makeBuffer to make sure the MemoryBuffer
has a name and the created module has a module identifier.

This is mainly for emitting warning messages from the linker. When we emit
warning message on a module, we can use the module identifier.

rdar://15985737

llvm-svn: 201114

llvm-svn: 201110

llvm-svn: 201108

Properly apply the fix intended by SVN r201032.

llvm-svn: 201036

llvm-svn: 201032

In some cases it is possible to have a personality 0 unwinding opcodes in the
extab (such as when .handlerdata is used in the assembly).  Simply decode the 3
opcodes for that case.

llvm-svn: 201030

The primary motivation for this pass is to separate the call graph
analysis used by the new pass manager's CGSCC pass management from the
existing call graph analysis pass. That analysis pass is (somewhat
unfortunately) over-constrained by the existing CallGraphSCCPassManager
requirements. Those requirements make it *really* hard to cleanly layer
the needed functionality for the new pass manager on top of the existing
analysis.

However, there are also a bunch of things that the pass manager would
specifically benefit from doing differently from the existing call graph
analysis, and this new implementation tries to address several of them:

- Be lazy about scanning function definitions. The existing pass eagerly
  scans the entire module to build the initial graph. This new pass is
  significantly more lazy, and I plan to push this even further to
  maximize locality during CGSCC walks.
- Don't use a single synthetic node to partition functions with an
  indirect call from functions whose address is taken. This node creates
  a huge choke-point which would preclude good parallelization across
  the fanout of the SCC graph when we got to the point of looking at
  such changes to LLVM.
- Use a memory dense and lightweight representation of the call graph
  rather than value handles and tracking call instructions. This will
  require explicit update calls instead of some updates working
  transparently, but should end up being significantly more efficient.
  The explicit update calls ended up being needed in many cases for the
  existing call graph so we don't really lose anything.
- Doesn't explicitly model SCCs and thus doesn't provide an "identity"
  for an SCC which is stable across updates. This is essential for the
  new pass manager to work correctly.
- Only form the graph necessary for traversing all of the functions in
  an SCC friendly order. This is a much simpler graph structure and
  should be more memory dense. It does limit the ways in which it is
  appropriate to use this analysis. I wish I had a better name than
  "call graph". I've commented extensively this aspect.

This is still very much a WIP, in fact it is really just the initial
bits. But it is about the fourth version of the initial bits that I've
implemented with each of the others running into really frustrating
problms. This looks like it will actually work and I'd like to split the
actual complexity across commits for the sake of my reviewers. =] The
rest of the implementation along with lots of wiring will follow
somewhat more rapidly now that there is a good path forward.

Naturally, this doesn't impact any of the existing optimizer. This code
is specific to the new pass manager.

A bunch of thanks are deserved for the various folks that have helped
with the design of this, especially Nick Lewycky who actually sat with
me to go through the fundamentals of the final version here.

llvm-svn: 200903

in my next patch. Sorry for the breakage.

llvm-svn: 200902

necessary until we add analyses to the driver, but I have such an
analysis ready and wanted to split this out. This is actually exercised
by the existing tests of the new pass manager as the analysis managers
are cross-checked and validated by the function and module managers.

llvm-svn: 200901

Clang itself was not using this. The only way to access it was via llc.

llvm-svn: 200862

It is not clear how much we should try to expose in getFlags. For example,
should there be a SF_Object and a SF_Text?

But for information that is already being exposed, we may as well use it in
llvm-nm.

llvm-svn: 200820

llvm-svn: 200808

No functional change.  Updated loops from:

    for (I = scc_begin(), E = scc_end(); I != E; ++I)

to:

    for (I = scc_begin(); !I.isAtEnd(); ++I)

for teh win.

llvm-svn: 200789

Until now, when a path in a gcno file included a directory, we would
emit our .gcov file in that directory, whereas gcov always emits the
file in the current directory. In doing so, this implements gcov's
strange name-mangling -p flag, which is needed to avoid clobbering
files when two with the same name exist in different directories.

The path mangling is a bit ugly and only handles unix-like paths, but
it's simple, and it doesn't make any guesses as to how it should
behave outside of what gcov documents. If we decide this should be
cross platform later, we can consider the compatibility implications
then.

llvm-svn: 200754

llvm-svn: 200741

When gcov is run without gcda data, it acts as if the counts are all
zero and labels the file as - to indicate that there was no data. We
should do the same.

llvm-svn: 200740

llvm-svn: 200727

None of the object formats require extra parsing to compute these flags,
so the method cannot fail.

llvm-svn: 200574

Oh sorry, I missed LTO.exports, ... I checked just only *.cpp(s).

llvm-svn: 200562

llvm-svn: 200560

llvm-svn: 200559

llvm-svn: 200493

COFF has only one symbol table.
MachO has a LC_DYSYMTAB, but that is not a symbol table, just extra info about
the one symbol table (LC_SYMTAB).
IR (coming soon) also has only one table.

llvm-svn: 200488

llvm-svn: 200484

utohexstr provides a temporary string, making it unsafe to use with the Twine
interface which will not copy the string.  Switch to using std::string.

llvm-svn: 200457

This is acceptted by clang and gcc, but MSVC seems to balk at it.  As it is
unneeded, simply drop it.  Fixes MSVC buildbots.

llvm-svn: 200456

exp2 is not available on Windows.  Fortunately, we are calculating powers of 2
with expontents within the range of [4,12].  Simply use an equivalent bitshift
operation to repair compilation with MSVC which does not provide this standard
function.

llvm-svn: 200454

Enhance the ARM specific parsing support in llvm-readobj to support attributes.
This allows for simpler tests to validate encoding of the build attributes as
specified in the ARM ELF specification.

llvm-svn: 200450

None of the object file formats reported error on iterator increment. In
retrospect, that is not too surprising: no object format stores symbols or
sections in a linked list or other structure that requires chasing pointers.
As a consequence, all error checking can be done on begin() and end().

This reduces the text segment of bin/llvm-readobj in my machine from 521233 to
518526 bytes.

llvm-svn: 200442

llvm-svn: 200433

This is a bit imperfect, as these options don't show up in the help as
is and single dash variants are accepted, which differs from gcov.
Unfortunately, this seems to be as good as it gets with the cl::opt
machinery, so it'll do as an incremental step.

llvm-svn: 200419

This Properly capitalizes and clarifies the help output from
llvm-cov. It also puts the llvm-only / non-gcov-compatible options in
their own category.

llvm-svn: 200418

Currently, llvm-cov isn't command-line compatible with gcov, which
accepts a source file name as its first parameter and infers the gcno
and gcda file names from that. This change keeps our -gcda and -gcno
options available for convenience in overriding this behaviour, but
adds the required parameter and inference behaviour as a compatible
default.

llvm-svn: 200417