The inalloca attribute is designed to support passing C++ objects by
value in the Microsoft C++ ABI. It behaves the same as byval, except
that it always implies that the argument is in memory and that the bytes
are never copied. This attribute allows the caller to take the address
of an outgoing argument's memory and execute arbitrary code to store
into it.
This patch adds basic IR support, docs, and verification. It does not
attempt to implement any lowering or fix any possibly broken transforms.
When this patch lands, a complete description of this feature should
appear at http://llvm.org/docs/InAlloca.html .
Differential Revision: http://llvm-reviews.chandlerc.com/D2173
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197645 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
File summaries will now be optionally outputted which will give line,
branching and call coverage info. Unfortunately, clang's current
instrumentation does not give enough information to deduce function
calls, something that gcc is able to do. Thus, no calls are always
outputted to be consistent with gcov output.
Also updated tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197606 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
This reapplies r197438 and fixes the link-time circular dependency between
IR and Support. The fix consists in moving the diagnostic support into IR.
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>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197508 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197438 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
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 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196626 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 currently breaks clang/test/CodeGen/code-coverage.c. The root cause
is that the newly introduced access to Funcs[j] is out of bounds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196365 91177308-0d34-0410-b5e6-96231b3b80d8
Added additional checks for the Identifier, CfgChecksum and Name for
each GCOVFunction. Also added function names in error messages.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196356 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
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
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196177 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196175 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196158 91177308-0d34-0410-b5e6-96231b3b80d8
Code scanner ran by Sylvestre Ledru got a no_return bug
in DebugInfo.cpp. Adding the return statements that
should be there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195772 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195747 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195538 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195525 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195519 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195505 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195451 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195445 91177308-0d34-0410-b5e6-96231b3b80d8
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
