llvm-svn: 197451

The patch adds a new LLVMContext::diagnose that can be used to communicate to
the front-end, if any, that something of interest happened.
The diagnostics are supported by a new abstraction, the DiagnosticInfo class.
The base class contains the following information:
- The kind of the report: What this is about.
- The severity of the report: How bad this is.

This patch also adds 2 classes:
- DiagnosticInfoInlineAsm: For inline asm reporting. Basically, this diagnostic
will be used to switch to the new diagnostic API for LLVMContext::emitError.
- DiagnosticStackSize: For stack size reporting. Comes as a replacement of the
hard coded warning in PEI.

This patch also features dynamic diagnostic identifiers. In other words plugins
can use this infrastructure for their own diagnostics (for more details, see
getNextAvailablePluginDiagnosticKind).

This patch introduces a new DiagnosticHandlerTy and a new DiagnosticContext in
the LLVMContext that should be set by the front-end to be able to map these
diagnostics in its own system.

http://llvm-reviews.chandlerc.com/D2376
<rdar://problem/15515174>

llvm-svn: 197438

Outputs branch information for unconditional branches in addition to
conditional branches. -b option must be enabled.

Also updated tests.

llvm-svn: 197432

llvm-svn: 197418

llvm-svn: 197335

Also update for the current naming style.

llvm-svn: 197283

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.

llvm-svn: 197198

llvm-svn: 196882

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.

llvm-svn: 196856

llvm-svn: 196637

llvm-svn: 196635

The sefault occurs due to an infinite loop when the verifier tries to
determine the size of a type of the form "%rt = type { %rt }" while
checking an alloca of the type.

llvm-svn: 196626

llvm-svn: 196604

llvm-svn: 196542

llvm-svn: 196541

llvm-svn: 196530

llvm-svn: 196473

This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.

llvm-svn: 196471

And add the proper fix.

llvm-svn: 196367

This currently breaks clang/test/CodeGen/code-coverage.c. The root cause
is that the newly introduced access to Funcs[j] is out of bounds.

llvm-svn: 196365

The function checksums are hashed from the concatenation of the function
name and line number.

llvm-svn: 196358

Added additional checks for the Identifier, CfgChecksum and Name for
each GCOVFunction. Also added function names in error messages.

llvm-svn: 196356

llvm-svn: 196354

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.

llvm-svn: 196353

Changed while to for loop. Removed unnecessary if statement.

llvm-svn: 196194

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).

llvm-svn: 196184

Each line stores all the blocks that execute on that line, instead of
only storing the line counts previously accumulated. This provides more
information for each line, and will be useful for options in enabling
block and branch information.

llvm-svn: 196177

Added GCOVEdge which are simple structs owned by the GCOVFunction that
stores the source and destination GCOVBlocks, as well as the counts.
Changed GCOVBlocks so that it stores a vector of source GCOVEdges and a
vector of destination GCOVEdges, rather than just the block number.

Storing the block number was only useful for knowing the number of edges
and for debug info. Using a struct is useful for traversing the edges,
especially back edges which may be needed later.

llvm-svn: 196175

There are now two functions: readGCNO() and readGCDA().

llvm-svn: 196173

Suggested by Eric.

llvm-svn: 196172

Add a helper function getDebugInfoVersionFromModule to return the debug info
version number for a module.

"Verifier/module-flags-1.ll" checks for verification errors.
It will seg fault when calling getDebugInfoVersionFromModule because of the
incorrect format for module flags in the testing case. We make
getModuleFlagsMetadata more robust by checking for error conditions.

PR17982

llvm-svn: 196158

llvm-svn: 195775

Code scanner ran by Sylvestre Ledru got a no_return bug
in DebugInfo.cpp. Adding the return statements that
should be there.

llvm-svn: 195772

of the two analysis managers into a CRTP base class that can be shared
and re-used in building any analysis manager. This will in turn simplify
adding yet another analysis manager to the system.

The base class provides all of the interface sugar for the analysis
manager delegating the functionality back through DerivedT methods which
operate on simple pass IDs. It also provides the pass registration,
storage, and lookup system which is common across the various
formulations of analysis managers.

llvm-svn: 195747

proxy. This lets a function pass query a module analysis manager.
However, the interface is const to indicate that only cached results can
be safely queried.

With this, I think the new pass manager is largely functionally complete
for modules and analyses. Still lots to test, and need to generalize to
SCCs and Loops, and need to build an adaptor layer to support the use of
existing Pass objects in the new managers.

llvm-svn: 195538

results.

This is the last piece of infrastructure needed to effectively support
querying *up* the analysis layers. The next step will be to introduce
a proxy which provides access to those layers with appropriate use of
const to direct queries to the safe interface.

llvm-svn: 195525

one function's analyses are invalidated at a time. Also switch the
preservation of the proxy to *fully* preserve the lower (function)
analyses.

Combined, this gets both upward and downward analysis invalidation to
a point I'm happy with:

- A function pass invalidates its function analyses, and its parent's
  module analyses.
- A module pass invalidates all of its functions' analyses including the
  set of which functions are in the module.
- A function pass can preserve a module analysis pass.
- If all function passes preserve a module analysis pass, that
  preservation persists. If any doesn't the module analysis is
  invalidated.
- A module pass can opt into managing *all* function analysis
  invalidation itself or *none*.
- The conservative default is none, and the proxy takes the maximally
  conservative approach that works even if the set of functions has
  changed.
- If a module pass opts into managing function analysis invalidation it
  has to propagate the invalidation itself, the proxy just does nothing.

The only thing really missing is a way to query for a cached analysis or
nothing at all. With this, function passes can more safely request
a cached module analysis pass without fear of it accidentally running
part way through.

llvm-svn: 195519

We can share the implementation between StripSymbols and dropping debug info
for metadata versions that do not match.

Also update the comments to match the implementation. A follow-on patch will
drop the "Debug Info Version" module flag in StripDebugInfo.

llvm-svn: 195505

run methods of the analysis passes.

Also generalizes and re-uses the SFINAE for transformation passes so
that users can write an analysis pass and only accept an analysis
manager if that is useful to their pass.

This completes the plumbing to make an analysis manager available
through every pass's run method if desired so that passes no longer need
to be constructed around them.

llvm-svn: 195451

This is supposed to be the whole type of the IR unit, and so we
shouldn't pass a pointer to it but rather the value itself. In turn, we
need to provide a 'Module *' as that type argument (for example). This
will become more relevant with SCCs or other units which may not be
passed as a pointer type, but also brings consistency with the
transformation pass templates.

llvm-svn: 195445