2013-12-18 01:47:22 +08:00
|
|
|
//===- llvm/Support/DiagnosticInfo.cpp - Diagnostic Definitions -*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines the different classes involved in low level diagnostics.
|
|
|
|
//
|
|
|
|
// Diagnostics reporting is still done as part of the LLVMContext.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-09-28 04:55:01 +08:00
|
|
|
#include "llvm/IR/DiagnosticInfo.h"
|
2014-05-22 22:19:46 +08:00
|
|
|
#include "LLVMContextImpl.h"
|
Output optimization remarks in YAML
(Re-committed after moving the template specialization under the yaml
namespace. GCC was complaining about this.)
This allows various presentation of this data using an external tool.
This was first recommended here[1].
As an example, consider this module:
1 int foo();
2 int bar();
3
4 int baz() {
5 return foo() + bar();
6 }
The inliner generates these missed-optimization remarks today (the
hotness information is pulled from PGO):
remark: /tmp/s.c:5:10: foo will not be inlined into baz (hotness: 30)
remark: /tmp/s.c:5:18: bar will not be inlined into baz (hotness: 30)
Now with -pass-remarks-output=<yaml-file>, we generate this YAML file:
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 10 }
Function: baz
Hotness: 30
Args:
- Callee: foo
- String: will not be inlined into
- Caller: baz
...
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 18 }
Function: baz
Hotness: 30
Args:
- Callee: bar
- String: will not be inlined into
- Caller: baz
...
This is a summary of the high-level decisions:
* There is a new streaming interface to emit optimization remarks.
E.g. for the inliner remark above:
ORE.emit(DiagnosticInfoOptimizationRemarkMissed(
DEBUG_TYPE, "NotInlined", &I)
<< NV("Callee", Callee) << " will not be inlined into "
<< NV("Caller", CS.getCaller()) << setIsVerbose());
NV stands for named value and allows the YAML client to process a remark
using its name (NotInlined) and the named arguments (Callee and Caller)
without parsing the text of the message.
Subsequent patches will update ORE users to use the new streaming API.
* I am using YAML I/O for writing the YAML file. YAML I/O requires you
to specify reading and writing at once but reading is highly non-trivial
for some of the more complex LLVM types. Since it's not clear that we
(ever) want to use LLVM to parse this YAML file, the code supports and
asserts that we're writing only.
On the other hand, I did experiment that the class hierarchy starting at
DiagnosticInfoOptimizationBase can be mapped back from YAML generated
here (see D24479).
* The YAML stream is stored in the LLVM context.
* In the example, we can probably further specify the IR value used,
i.e. print "Function" rather than "Value".
* As before hotness is computed in the analysis pass instead of
DiganosticInfo. This avoids the layering problem since BFI is in
Analysis while DiagnosticInfo is in IR.
[1] https://reviews.llvm.org/D19678#419445
Differential Revision: https://reviews.llvm.org/D24587
llvm-svn: 282539
2016-09-28 04:55:07 +08:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2013-12-18 01:47:22 +08:00
|
|
|
#include "llvm/ADT/Twine.h"
|
|
|
|
#include "llvm/IR/Constants.h"
|
2014-04-09 00:42:34 +08:00
|
|
|
#include "llvm/IR/DebugInfo.h"
|
2013-12-18 01:47:22 +08:00
|
|
|
#include "llvm/IR/DiagnosticPrinter.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
#include "llvm/IR/Instruction.h"
|
|
|
|
#include "llvm/IR/Metadata.h"
|
2014-04-09 00:42:34 +08:00
|
|
|
#include "llvm/IR/Module.h"
|
2014-05-23 01:19:01 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Support/Regex.h"
|
2015-06-12 01:30:34 +08:00
|
|
|
#include <atomic>
|
2013-12-18 01:47:22 +08:00
|
|
|
#include <string>
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2014-05-23 01:19:01 +08:00
|
|
|
namespace {
|
|
|
|
|
|
|
|
/// \brief Regular expression corresponding to the value given in one of the
|
|
|
|
/// -pass-remarks* command line flags. Passes whose name matches this regexp
|
|
|
|
/// will emit a diagnostic when calling the associated diagnostic function
|
|
|
|
/// (emitOptimizationRemark, emitOptimizationRemarkMissed or
|
|
|
|
/// emitOptimizationRemarkAnalysis).
|
|
|
|
struct PassRemarksOpt {
|
|
|
|
std::shared_ptr<Regex> Pattern;
|
|
|
|
|
|
|
|
void operator=(const std::string &Val) {
|
|
|
|
// Create a regexp object to match pass names for emitOptimizationRemark.
|
|
|
|
if (!Val.empty()) {
|
|
|
|
Pattern = std::make_shared<Regex>(Val);
|
|
|
|
std::string RegexError;
|
|
|
|
if (!Pattern->isValid(RegexError))
|
|
|
|
report_fatal_error("Invalid regular expression '" + Val +
|
|
|
|
"' in -pass-remarks: " + RegexError,
|
|
|
|
false);
|
|
|
|
}
|
2015-07-23 04:46:11 +08:00
|
|
|
}
|
2014-05-23 01:19:01 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static PassRemarksOpt PassRemarksOptLoc;
|
|
|
|
static PassRemarksOpt PassRemarksMissedOptLoc;
|
|
|
|
static PassRemarksOpt PassRemarksAnalysisOptLoc;
|
|
|
|
|
|
|
|
// -pass-remarks
|
|
|
|
// Command line flag to enable emitOptimizationRemark()
|
|
|
|
static cl::opt<PassRemarksOpt, true, cl::parser<std::string>>
|
|
|
|
PassRemarks("pass-remarks", cl::value_desc("pattern"),
|
|
|
|
cl::desc("Enable optimization remarks from passes whose name match "
|
|
|
|
"the given regular expression"),
|
|
|
|
cl::Hidden, cl::location(PassRemarksOptLoc), cl::ValueRequired,
|
|
|
|
cl::ZeroOrMore);
|
|
|
|
|
|
|
|
// -pass-remarks-missed
|
|
|
|
// Command line flag to enable emitOptimizationRemarkMissed()
|
|
|
|
static cl::opt<PassRemarksOpt, true, cl::parser<std::string>> PassRemarksMissed(
|
|
|
|
"pass-remarks-missed", cl::value_desc("pattern"),
|
|
|
|
cl::desc("Enable missed optimization remarks from passes whose name match "
|
|
|
|
"the given regular expression"),
|
|
|
|
cl::Hidden, cl::location(PassRemarksMissedOptLoc), cl::ValueRequired,
|
|
|
|
cl::ZeroOrMore);
|
|
|
|
|
|
|
|
// -pass-remarks-analysis
|
|
|
|
// Command line flag to enable emitOptimizationRemarkAnalysis()
|
|
|
|
static cl::opt<PassRemarksOpt, true, cl::parser<std::string>>
|
|
|
|
PassRemarksAnalysis(
|
|
|
|
"pass-remarks-analysis", cl::value_desc("pattern"),
|
|
|
|
cl::desc(
|
|
|
|
"Enable optimization analysis remarks from passes whose name match "
|
|
|
|
"the given regular expression"),
|
|
|
|
cl::Hidden, cl::location(PassRemarksAnalysisOptLoc), cl::ValueRequired,
|
|
|
|
cl::ZeroOrMore);
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2014-05-23 01:19:01 +08:00
|
|
|
|
2013-12-18 18:12:06 +08:00
|
|
|
int llvm::getNextAvailablePluginDiagnosticKind() {
|
2015-06-12 01:30:34 +08:00
|
|
|
static std::atomic<int> PluginKindID(DK_FirstPluginKind);
|
|
|
|
return ++PluginKindID;
|
2013-12-18 01:47:22 +08:00
|
|
|
}
|
|
|
|
|
2016-09-28 06:19:23 +08:00
|
|
|
const char *OptimizationRemarkAnalysis::AlwaysPrint = "";
|
2015-08-11 09:09:15 +08:00
|
|
|
|
2013-12-18 01:47:22 +08:00
|
|
|
DiagnosticInfoInlineAsm::DiagnosticInfoInlineAsm(const Instruction &I,
|
|
|
|
const Twine &MsgStr,
|
|
|
|
DiagnosticSeverity Severity)
|
|
|
|
: DiagnosticInfo(DK_InlineAsm, Severity), LocCookie(0), MsgStr(MsgStr),
|
|
|
|
Instr(&I) {
|
2014-11-12 05:30:22 +08:00
|
|
|
if (const MDNode *SrcLoc = I.getMetadata("srcloc")) {
|
2013-12-18 01:47:22 +08:00
|
|
|
if (SrcLoc->getNumOperands() != 0)
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
if (const auto *CI =
|
|
|
|
mdconst::dyn_extract<ConstantInt>(SrcLoc->getOperand(0)))
|
2013-12-18 01:47:22 +08:00
|
|
|
LocCookie = CI->getZExtValue();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void DiagnosticInfoInlineAsm::print(DiagnosticPrinter &DP) const {
|
|
|
|
DP << getMsgStr();
|
|
|
|
if (getLocCookie())
|
|
|
|
DP << " at line " << getLocCookie();
|
|
|
|
}
|
|
|
|
|
2016-06-21 02:13:04 +08:00
|
|
|
void DiagnosticInfoResourceLimit::print(DiagnosticPrinter &DP) const {
|
|
|
|
DP << getResourceName() << " limit";
|
|
|
|
|
|
|
|
if (getResourceLimit() != 0)
|
|
|
|
DP << " of " << getResourceLimit();
|
|
|
|
|
|
|
|
DP << " exceeded (" << getResourceSize() << ") in " << getFunction();
|
2013-12-18 01:47:22 +08:00
|
|
|
}
|
2014-01-16 09:51:12 +08:00
|
|
|
|
|
|
|
void DiagnosticInfoDebugMetadataVersion::print(DiagnosticPrinter &DP) const {
|
2014-02-05 07:49:02 +08:00
|
|
|
DP << "ignoring debug info with an invalid version (" << getMetadataVersion()
|
|
|
|
<< ") in " << getModule();
|
2014-01-16 09:51:12 +08:00
|
|
|
}
|
2014-03-15 05:58:59 +08:00
|
|
|
|
2016-05-10 03:57:29 +08:00
|
|
|
void DiagnosticInfoIgnoringInvalidDebugMetadata::print(
|
|
|
|
DiagnosticPrinter &DP) const {
|
|
|
|
DP << "ignoring invalid debug info in " << getModule().getModuleIdentifier();
|
|
|
|
}
|
|
|
|
|
2014-03-15 05:58:59 +08:00
|
|
|
void DiagnosticInfoSampleProfile::print(DiagnosticPrinter &DP) const {
|
2015-11-03 04:01:13 +08:00
|
|
|
if (!FileName.empty()) {
|
|
|
|
DP << getFileName();
|
|
|
|
if (LineNum > 0)
|
|
|
|
DP << ":" << getLineNum();
|
|
|
|
DP << ": ";
|
|
|
|
}
|
2014-03-15 05:58:59 +08:00
|
|
|
DP << getMsg();
|
|
|
|
}
|
2014-04-09 00:42:34 +08:00
|
|
|
|
2015-12-10 02:08:16 +08:00
|
|
|
void DiagnosticInfoPGOProfile::print(DiagnosticPrinter &DP) const {
|
|
|
|
if (getFileName())
|
|
|
|
DP << getFileName() << ": ";
|
|
|
|
DP << getMsg();
|
|
|
|
}
|
|
|
|
|
2016-02-02 21:52:43 +08:00
|
|
|
bool DiagnosticInfoWithDebugLocBase::isLocationAvailable() const {
|
2015-03-31 03:40:05 +08:00
|
|
|
return getDebugLoc();
|
2014-04-09 00:42:34 +08:00
|
|
|
}
|
|
|
|
|
2016-02-02 21:52:43 +08:00
|
|
|
void DiagnosticInfoWithDebugLocBase::getLocation(StringRef *Filename,
|
2014-07-16 08:36:00 +08:00
|
|
|
unsigned *Line,
|
|
|
|
unsigned *Column) const {
|
2015-04-30 00:38:44 +08:00
|
|
|
DILocation *L = getDebugLoc();
|
2015-05-05 02:08:35 +08:00
|
|
|
assert(L != nullptr && "debug location is invalid");
|
2015-04-14 09:35:55 +08:00
|
|
|
*Filename = L->getFilename();
|
|
|
|
*Line = L->getLine();
|
|
|
|
*Column = L->getColumn();
|
2014-04-09 00:42:34 +08:00
|
|
|
}
|
|
|
|
|
2016-02-02 21:52:43 +08:00
|
|
|
const std::string DiagnosticInfoWithDebugLocBase::getLocationStr() const {
|
2014-04-09 00:42:34 +08:00
|
|
|
StringRef Filename("<unknown>");
|
|
|
|
unsigned Line = 0;
|
|
|
|
unsigned Column = 0;
|
|
|
|
if (isLocationAvailable())
|
|
|
|
getLocation(&Filename, &Line, &Column);
|
2015-03-30 23:42:36 +08:00
|
|
|
return (Filename + ":" + Twine(Line) + ":" + Twine(Column)).str();
|
2014-04-09 00:42:34 +08:00
|
|
|
}
|
2016-12-02 01:34:44 +08:00
|
|
|
|
2016-10-08 12:47:20 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, Value *V)
|
2016-12-02 01:34:44 +08:00
|
|
|
: Key(Key) {
|
2016-11-08 06:41:13 +08:00
|
|
|
if (auto *F = dyn_cast<Function>(V)) {
|
|
|
|
if (DISubprogram *SP = F->getSubprogram())
|
|
|
|
DLoc = DebugLoc::get(SP->getScopeLine(), 0, SP);
|
|
|
|
}
|
|
|
|
else if (auto *I = dyn_cast<Instruction>(V))
|
|
|
|
DLoc = I->getDebugLoc();
|
2016-12-02 01:34:44 +08:00
|
|
|
|
|
|
|
// Only include names that correspond to user variables. FIXME: we should use
|
|
|
|
// debug info if available to get the name of the user variable.
|
|
|
|
if (isa<llvm::Argument>(V) || isa<GlobalValue>(V))
|
|
|
|
Val = GlobalValue::getRealLinkageName(V->getName());
|
|
|
|
else if (isa<Constant>(V)) {
|
|
|
|
raw_string_ostream OS(Val);
|
|
|
|
V->printAsOperand(OS, /*PrintType=*/false);
|
|
|
|
} else if (auto *I = dyn_cast<Instruction>(V))
|
|
|
|
Val = I->getOpcodeName();
|
2016-11-08 06:41:13 +08:00
|
|
|
}
|
2014-04-09 00:42:34 +08:00
|
|
|
|
2016-12-02 00:40:32 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, Type *T)
|
|
|
|
: Key(Key) {
|
|
|
|
raw_string_ostream OS(Val);
|
|
|
|
OS << *T;
|
|
|
|
}
|
|
|
|
|
Output optimization remarks in YAML
(Re-committed after moving the template specialization under the yaml
namespace. GCC was complaining about this.)
This allows various presentation of this data using an external tool.
This was first recommended here[1].
As an example, consider this module:
1 int foo();
2 int bar();
3
4 int baz() {
5 return foo() + bar();
6 }
The inliner generates these missed-optimization remarks today (the
hotness information is pulled from PGO):
remark: /tmp/s.c:5:10: foo will not be inlined into baz (hotness: 30)
remark: /tmp/s.c:5:18: bar will not be inlined into baz (hotness: 30)
Now with -pass-remarks-output=<yaml-file>, we generate this YAML file:
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 10 }
Function: baz
Hotness: 30
Args:
- Callee: foo
- String: will not be inlined into
- Caller: baz
...
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 18 }
Function: baz
Hotness: 30
Args:
- Callee: bar
- String: will not be inlined into
- Caller: baz
...
This is a summary of the high-level decisions:
* There is a new streaming interface to emit optimization remarks.
E.g. for the inliner remark above:
ORE.emit(DiagnosticInfoOptimizationRemarkMissed(
DEBUG_TYPE, "NotInlined", &I)
<< NV("Callee", Callee) << " will not be inlined into "
<< NV("Caller", CS.getCaller()) << setIsVerbose());
NV stands for named value and allows the YAML client to process a remark
using its name (NotInlined) and the named arguments (Callee and Caller)
without parsing the text of the message.
Subsequent patches will update ORE users to use the new streaming API.
* I am using YAML I/O for writing the YAML file. YAML I/O requires you
to specify reading and writing at once but reading is highly non-trivial
for some of the more complex LLVM types. Since it's not clear that we
(ever) want to use LLVM to parse this YAML file, the code supports and
asserts that we're writing only.
On the other hand, I did experiment that the class hierarchy starting at
DiagnosticInfoOptimizationBase can be mapped back from YAML generated
here (see D24479).
* The YAML stream is stored in the LLVM context.
* In the example, we can probably further specify the IR value used,
i.e. print "Function" rather than "Value".
* As before hotness is computed in the analysis pass instead of
DiganosticInfo. This avoids the layering problem since BFI is in
Analysis while DiagnosticInfo is in IR.
[1] https://reviews.llvm.org/D19678#419445
Differential Revision: https://reviews.llvm.org/D24587
llvm-svn: 282539
2016-09-28 04:55:07 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, int N)
|
|
|
|
: Key(Key), Val(itostr(N)) {}
|
|
|
|
|
2016-09-30 00:23:12 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, unsigned N)
|
|
|
|
: Key(Key), Val(utostr(N)) {}
|
|
|
|
|
2014-07-16 08:36:00 +08:00
|
|
|
void DiagnosticInfoOptimizationBase::print(DiagnosticPrinter &DP) const {
|
2014-04-09 00:42:34 +08:00
|
|
|
DP << getLocationStr() << ": " << getMsg();
|
2016-07-16 01:23:20 +08:00
|
|
|
if (Hotness)
|
|
|
|
DP << " (hotness: " << *Hotness << ")";
|
2014-04-09 00:42:34 +08:00
|
|
|
}
|
2014-05-22 22:19:46 +08:00
|
|
|
|
2016-09-28 07:47:03 +08:00
|
|
|
OptimizationRemark::OptimizationRemark(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
|
|
|
const DebugLoc &DLoc, Value *CodeRegion)
|
|
|
|
: DiagnosticInfoOptimizationBase(
|
|
|
|
DK_OptimizationRemark, DS_Remark, PassName, RemarkName,
|
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), DLoc, CodeRegion) {}
|
|
|
|
|
2016-09-30 08:42:43 +08:00
|
|
|
OptimizationRemark::OptimizationRemark(const char *PassName,
|
|
|
|
StringRef RemarkName, Instruction *Inst)
|
|
|
|
: DiagnosticInfoOptimizationBase(DK_OptimizationRemark, DS_Remark, PassName,
|
|
|
|
RemarkName,
|
|
|
|
*Inst->getParent()->getParent(),
|
|
|
|
Inst->getDebugLoc(), Inst->getParent()) {}
|
|
|
|
|
2016-09-28 06:19:23 +08:00
|
|
|
bool OptimizationRemark::isEnabled() const {
|
2014-05-23 01:19:01 +08:00
|
|
|
return PassRemarksOptLoc.Pattern &&
|
|
|
|
PassRemarksOptLoc.Pattern->match(getPassName());
|
2014-05-22 22:19:46 +08:00
|
|
|
}
|
|
|
|
|
2016-09-28 07:47:03 +08:00
|
|
|
OptimizationRemarkMissed::OptimizationRemarkMissed(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
|
|
|
const DebugLoc &DLoc,
|
|
|
|
Value *CodeRegion)
|
|
|
|
: DiagnosticInfoOptimizationBase(
|
|
|
|
DK_OptimizationRemarkMissed, DS_Remark, PassName, RemarkName,
|
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), DLoc, CodeRegion) {}
|
|
|
|
|
2016-09-28 06:19:23 +08:00
|
|
|
OptimizationRemarkMissed::OptimizationRemarkMissed(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
|
|
|
Instruction *Inst)
|
Output optimization remarks in YAML
(Re-committed after moving the template specialization under the yaml
namespace. GCC was complaining about this.)
This allows various presentation of this data using an external tool.
This was first recommended here[1].
As an example, consider this module:
1 int foo();
2 int bar();
3
4 int baz() {
5 return foo() + bar();
6 }
The inliner generates these missed-optimization remarks today (the
hotness information is pulled from PGO):
remark: /tmp/s.c:5:10: foo will not be inlined into baz (hotness: 30)
remark: /tmp/s.c:5:18: bar will not be inlined into baz (hotness: 30)
Now with -pass-remarks-output=<yaml-file>, we generate this YAML file:
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 10 }
Function: baz
Hotness: 30
Args:
- Callee: foo
- String: will not be inlined into
- Caller: baz
...
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 18 }
Function: baz
Hotness: 30
Args:
- Callee: bar
- String: will not be inlined into
- Caller: baz
...
This is a summary of the high-level decisions:
* There is a new streaming interface to emit optimization remarks.
E.g. for the inliner remark above:
ORE.emit(DiagnosticInfoOptimizationRemarkMissed(
DEBUG_TYPE, "NotInlined", &I)
<< NV("Callee", Callee) << " will not be inlined into "
<< NV("Caller", CS.getCaller()) << setIsVerbose());
NV stands for named value and allows the YAML client to process a remark
using its name (NotInlined) and the named arguments (Callee and Caller)
without parsing the text of the message.
Subsequent patches will update ORE users to use the new streaming API.
* I am using YAML I/O for writing the YAML file. YAML I/O requires you
to specify reading and writing at once but reading is highly non-trivial
for some of the more complex LLVM types. Since it's not clear that we
(ever) want to use LLVM to parse this YAML file, the code supports and
asserts that we're writing only.
On the other hand, I did experiment that the class hierarchy starting at
DiagnosticInfoOptimizationBase can be mapped back from YAML generated
here (see D24479).
* The YAML stream is stored in the LLVM context.
* In the example, we can probably further specify the IR value used,
i.e. print "Function" rather than "Value".
* As before hotness is computed in the analysis pass instead of
DiganosticInfo. This avoids the layering problem since BFI is in
Analysis while DiagnosticInfo is in IR.
[1] https://reviews.llvm.org/D19678#419445
Differential Revision: https://reviews.llvm.org/D24587
llvm-svn: 282539
2016-09-28 04:55:07 +08:00
|
|
|
: DiagnosticInfoOptimizationBase(DK_OptimizationRemarkMissed, DS_Remark,
|
|
|
|
PassName, RemarkName,
|
|
|
|
*Inst->getParent()->getParent(),
|
|
|
|
Inst->getDebugLoc(), Inst->getParent()) {}
|
|
|
|
|
2016-09-28 06:19:23 +08:00
|
|
|
bool OptimizationRemarkMissed::isEnabled() const {
|
2014-05-23 01:19:01 +08:00
|
|
|
return PassRemarksMissedOptLoc.Pattern &&
|
|
|
|
PassRemarksMissedOptLoc.Pattern->match(getPassName());
|
2014-05-22 22:19:46 +08:00
|
|
|
}
|
|
|
|
|
2016-09-30 00:23:12 +08:00
|
|
|
OptimizationRemarkAnalysis::OptimizationRemarkAnalysis(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
|
|
|
const DebugLoc &DLoc,
|
|
|
|
Value *CodeRegion)
|
|
|
|
: DiagnosticInfoOptimizationBase(
|
|
|
|
DK_OptimizationRemarkAnalysis, DS_Remark, PassName, RemarkName,
|
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), DLoc, CodeRegion) {}
|
|
|
|
|
2016-09-28 07:47:03 +08:00
|
|
|
OptimizationRemarkAnalysis::OptimizationRemarkAnalysis(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
|
|
|
Instruction *Inst)
|
|
|
|
: DiagnosticInfoOptimizationBase(DK_OptimizationRemarkAnalysis, DS_Remark,
|
|
|
|
PassName, RemarkName,
|
|
|
|
*Inst->getParent()->getParent(),
|
|
|
|
Inst->getDebugLoc(), Inst->getParent()) {}
|
|
|
|
|
2016-09-30 02:04:47 +08:00
|
|
|
OptimizationRemarkAnalysis::OptimizationRemarkAnalysis(enum DiagnosticKind Kind,
|
|
|
|
const char *PassName,
|
|
|
|
StringRef RemarkName,
|
|
|
|
const DebugLoc &DLoc,
|
|
|
|
Value *CodeRegion)
|
|
|
|
: DiagnosticInfoOptimizationBase(Kind, DS_Remark, PassName, RemarkName,
|
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(),
|
|
|
|
DLoc, CodeRegion) {}
|
|
|
|
|
2016-09-28 06:19:23 +08:00
|
|
|
bool OptimizationRemarkAnalysis::isEnabled() const {
|
2016-06-29 12:55:19 +08:00
|
|
|
return shouldAlwaysPrint() ||
|
2015-08-11 09:09:15 +08:00
|
|
|
(PassRemarksAnalysisOptLoc.Pattern &&
|
|
|
|
PassRemarksAnalysisOptLoc.Pattern->match(getPassName()));
|
2014-05-22 22:19:46 +08:00
|
|
|
}
|
|
|
|
|
2015-06-16 04:30:22 +08:00
|
|
|
void DiagnosticInfoMIRParser::print(DiagnosticPrinter &DP) const {
|
|
|
|
DP << Diagnostic;
|
|
|
|
}
|
|
|
|
|
2014-05-22 22:19:46 +08:00
|
|
|
void llvm::emitOptimizationRemark(LLVMContext &Ctx, const char *PassName,
|
|
|
|
const Function &Fn, const DebugLoc &DLoc,
|
|
|
|
const Twine &Msg) {
|
2016-09-28 06:19:23 +08:00
|
|
|
Ctx.diagnose(OptimizationRemark(PassName, Fn, DLoc, Msg));
|
2014-05-22 22:19:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void llvm::emitOptimizationRemarkMissed(LLVMContext &Ctx, const char *PassName,
|
|
|
|
const Function &Fn,
|
|
|
|
const DebugLoc &DLoc,
|
|
|
|
const Twine &Msg) {
|
2016-09-28 06:19:23 +08:00
|
|
|
Ctx.diagnose(OptimizationRemarkMissed(PassName, Fn, DLoc, Msg));
|
2014-05-22 22:19:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void llvm::emitOptimizationRemarkAnalysis(LLVMContext &Ctx,
|
|
|
|
const char *PassName,
|
|
|
|
const Function &Fn,
|
|
|
|
const DebugLoc &DLoc,
|
|
|
|
const Twine &Msg) {
|
2016-09-28 06:19:23 +08:00
|
|
|
Ctx.diagnose(OptimizationRemarkAnalysis(PassName, Fn, DLoc, Msg));
|
2014-05-22 22:19:46 +08:00
|
|
|
}
|
2014-07-16 08:36:00 +08:00
|
|
|
|
2015-08-11 03:51:46 +08:00
|
|
|
void llvm::emitOptimizationRemarkAnalysisFPCommute(LLVMContext &Ctx,
|
|
|
|
const char *PassName,
|
|
|
|
const Function &Fn,
|
|
|
|
const DebugLoc &DLoc,
|
|
|
|
const Twine &Msg) {
|
2016-09-28 06:19:23 +08:00
|
|
|
Ctx.diagnose(OptimizationRemarkAnalysisFPCommute(PassName, Fn, DLoc, Msg));
|
2015-08-11 03:51:46 +08:00
|
|
|
}
|
|
|
|
|
2015-08-11 07:01:55 +08:00
|
|
|
void llvm::emitOptimizationRemarkAnalysisAliasing(LLVMContext &Ctx,
|
|
|
|
const char *PassName,
|
|
|
|
const Function &Fn,
|
|
|
|
const DebugLoc &DLoc,
|
|
|
|
const Twine &Msg) {
|
2016-09-28 06:19:23 +08:00
|
|
|
Ctx.diagnose(OptimizationRemarkAnalysisAliasing(PassName, Fn, DLoc, Msg));
|
2015-08-11 07:01:55 +08:00
|
|
|
}
|
|
|
|
|
2014-07-19 03:36:04 +08:00
|
|
|
bool DiagnosticInfoOptimizationFailure::isEnabled() const {
|
2014-07-16 08:36:00 +08:00
|
|
|
// Only print warnings.
|
|
|
|
return getSeverity() == DS_Warning;
|
|
|
|
}
|
|
|
|
|
2016-02-02 21:52:43 +08:00
|
|
|
void DiagnosticInfoUnsupported::print(DiagnosticPrinter &DP) const {
|
|
|
|
std::string Str;
|
|
|
|
raw_string_ostream OS(Str);
|
|
|
|
|
|
|
|
OS << getLocationStr() << ": in function " << getFunction().getName() << ' '
|
|
|
|
<< *getFunction().getFunctionType() << ": " << Msg << '\n';
|
|
|
|
OS.flush();
|
|
|
|
DP << Str;
|
|
|
|
}
|
|
|
|
|
2014-07-16 08:36:00 +08:00
|
|
|
void llvm::emitLoopVectorizeWarning(LLVMContext &Ctx, const Function &Fn,
|
|
|
|
const DebugLoc &DLoc, const Twine &Msg) {
|
2014-07-19 03:36:04 +08:00
|
|
|
Ctx.diagnose(DiagnosticInfoOptimizationFailure(
|
2014-07-16 08:36:00 +08:00
|
|
|
Fn, DLoc, Twine("loop not vectorized: " + Msg)));
|
|
|
|
}
|
|
|
|
|
|
|
|
void llvm::emitLoopInterleaveWarning(LLVMContext &Ctx, const Function &Fn,
|
|
|
|
const DebugLoc &DLoc, const Twine &Msg) {
|
2014-07-19 03:36:04 +08:00
|
|
|
Ctx.diagnose(DiagnosticInfoOptimizationFailure(
|
2014-07-16 08:36:00 +08:00
|
|
|
Fn, DLoc, Twine("loop not interleaved: " + Msg)));
|
|
|
|
}
|
2016-09-01 02:42:55 +08:00
|
|
|
|
|
|
|
void DiagnosticInfoISelFallback::print(DiagnosticPrinter &DP) const {
|
|
|
|
DP << "Instruction selection used fallback path for " << getFunction();
|
|
|
|
}
|
Output optimization remarks in YAML
(Re-committed after moving the template specialization under the yaml
namespace. GCC was complaining about this.)
This allows various presentation of this data using an external tool.
This was first recommended here[1].
As an example, consider this module:
1 int foo();
2 int bar();
3
4 int baz() {
5 return foo() + bar();
6 }
The inliner generates these missed-optimization remarks today (the
hotness information is pulled from PGO):
remark: /tmp/s.c:5:10: foo will not be inlined into baz (hotness: 30)
remark: /tmp/s.c:5:18: bar will not be inlined into baz (hotness: 30)
Now with -pass-remarks-output=<yaml-file>, we generate this YAML file:
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 10 }
Function: baz
Hotness: 30
Args:
- Callee: foo
- String: will not be inlined into
- Caller: baz
...
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 18 }
Function: baz
Hotness: 30
Args:
- Callee: bar
- String: will not be inlined into
- Caller: baz
...
This is a summary of the high-level decisions:
* There is a new streaming interface to emit optimization remarks.
E.g. for the inliner remark above:
ORE.emit(DiagnosticInfoOptimizationRemarkMissed(
DEBUG_TYPE, "NotInlined", &I)
<< NV("Callee", Callee) << " will not be inlined into "
<< NV("Caller", CS.getCaller()) << setIsVerbose());
NV stands for named value and allows the YAML client to process a remark
using its name (NotInlined) and the named arguments (Callee and Caller)
without parsing the text of the message.
Subsequent patches will update ORE users to use the new streaming API.
* I am using YAML I/O for writing the YAML file. YAML I/O requires you
to specify reading and writing at once but reading is highly non-trivial
for some of the more complex LLVM types. Since it's not clear that we
(ever) want to use LLVM to parse this YAML file, the code supports and
asserts that we're writing only.
On the other hand, I did experiment that the class hierarchy starting at
DiagnosticInfoOptimizationBase can be mapped back from YAML generated
here (see D24479).
* The YAML stream is stored in the LLVM context.
* In the example, we can probably further specify the IR value used,
i.e. print "Function" rather than "Value".
* As before hotness is computed in the analysis pass instead of
DiganosticInfo. This avoids the layering problem since BFI is in
Analysis while DiagnosticInfo is in IR.
[1] https://reviews.llvm.org/D19678#419445
Differential Revision: https://reviews.llvm.org/D24587
llvm-svn: 282539
2016-09-28 04:55:07 +08:00
|
|
|
|
|
|
|
DiagnosticInfoOptimizationBase &DiagnosticInfoOptimizationBase::
|
|
|
|
operator<<(StringRef S) {
|
|
|
|
Args.emplace_back(S);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
DiagnosticInfoOptimizationBase &DiagnosticInfoOptimizationBase::
|
|
|
|
operator<<(Argument A) {
|
|
|
|
Args.push_back(std::move(A));
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
DiagnosticInfoOptimizationBase &DiagnosticInfoOptimizationBase::
|
|
|
|
operator<<(setIsVerbose V) {
|
|
|
|
IsVerbose = true;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
2016-12-02 01:34:44 +08:00
|
|
|
DiagnosticInfoOptimizationBase &DiagnosticInfoOptimizationBase::
|
|
|
|
operator<<(setExtraArgs EA) {
|
|
|
|
FirstExtraArgIndex = Args.size();
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
Output optimization remarks in YAML
(Re-committed after moving the template specialization under the yaml
namespace. GCC was complaining about this.)
This allows various presentation of this data using an external tool.
This was first recommended here[1].
As an example, consider this module:
1 int foo();
2 int bar();
3
4 int baz() {
5 return foo() + bar();
6 }
The inliner generates these missed-optimization remarks today (the
hotness information is pulled from PGO):
remark: /tmp/s.c:5:10: foo will not be inlined into baz (hotness: 30)
remark: /tmp/s.c:5:18: bar will not be inlined into baz (hotness: 30)
Now with -pass-remarks-output=<yaml-file>, we generate this YAML file:
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 10 }
Function: baz
Hotness: 30
Args:
- Callee: foo
- String: will not be inlined into
- Caller: baz
...
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 18 }
Function: baz
Hotness: 30
Args:
- Callee: bar
- String: will not be inlined into
- Caller: baz
...
This is a summary of the high-level decisions:
* There is a new streaming interface to emit optimization remarks.
E.g. for the inliner remark above:
ORE.emit(DiagnosticInfoOptimizationRemarkMissed(
DEBUG_TYPE, "NotInlined", &I)
<< NV("Callee", Callee) << " will not be inlined into "
<< NV("Caller", CS.getCaller()) << setIsVerbose());
NV stands for named value and allows the YAML client to process a remark
using its name (NotInlined) and the named arguments (Callee and Caller)
without parsing the text of the message.
Subsequent patches will update ORE users to use the new streaming API.
* I am using YAML I/O for writing the YAML file. YAML I/O requires you
to specify reading and writing at once but reading is highly non-trivial
for some of the more complex LLVM types. Since it's not clear that we
(ever) want to use LLVM to parse this YAML file, the code supports and
asserts that we're writing only.
On the other hand, I did experiment that the class hierarchy starting at
DiagnosticInfoOptimizationBase can be mapped back from YAML generated
here (see D24479).
* The YAML stream is stored in the LLVM context.
* In the example, we can probably further specify the IR value used,
i.e. print "Function" rather than "Value".
* As before hotness is computed in the analysis pass instead of
DiganosticInfo. This avoids the layering problem since BFI is in
Analysis while DiagnosticInfo is in IR.
[1] https://reviews.llvm.org/D19678#419445
Differential Revision: https://reviews.llvm.org/D24587
llvm-svn: 282539
2016-09-28 04:55:07 +08:00
|
|
|
std::string DiagnosticInfoOptimizationBase::getMsg() const {
|
|
|
|
std::string Str;
|
|
|
|
raw_string_ostream OS(Str);
|
2016-12-02 01:34:44 +08:00
|
|
|
for (const DiagnosticInfoOptimizationBase::Argument &Arg :
|
|
|
|
make_range(Args.begin(), FirstExtraArgIndex == -1
|
|
|
|
? Args.end()
|
|
|
|
: Args.begin() + FirstExtraArgIndex))
|
Output optimization remarks in YAML
(Re-committed after moving the template specialization under the yaml
namespace. GCC was complaining about this.)
This allows various presentation of this data using an external tool.
This was first recommended here[1].
As an example, consider this module:
1 int foo();
2 int bar();
3
4 int baz() {
5 return foo() + bar();
6 }
The inliner generates these missed-optimization remarks today (the
hotness information is pulled from PGO):
remark: /tmp/s.c:5:10: foo will not be inlined into baz (hotness: 30)
remark: /tmp/s.c:5:18: bar will not be inlined into baz (hotness: 30)
Now with -pass-remarks-output=<yaml-file>, we generate this YAML file:
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 10 }
Function: baz
Hotness: 30
Args:
- Callee: foo
- String: will not be inlined into
- Caller: baz
...
--- !Missed
Pass: inline
Name: NotInlined
DebugLoc: { File: /tmp/s.c, Line: 5, Column: 18 }
Function: baz
Hotness: 30
Args:
- Callee: bar
- String: will not be inlined into
- Caller: baz
...
This is a summary of the high-level decisions:
* There is a new streaming interface to emit optimization remarks.
E.g. for the inliner remark above:
ORE.emit(DiagnosticInfoOptimizationRemarkMissed(
DEBUG_TYPE, "NotInlined", &I)
<< NV("Callee", Callee) << " will not be inlined into "
<< NV("Caller", CS.getCaller()) << setIsVerbose());
NV stands for named value and allows the YAML client to process a remark
using its name (NotInlined) and the named arguments (Callee and Caller)
without parsing the text of the message.
Subsequent patches will update ORE users to use the new streaming API.
* I am using YAML I/O for writing the YAML file. YAML I/O requires you
to specify reading and writing at once but reading is highly non-trivial
for some of the more complex LLVM types. Since it's not clear that we
(ever) want to use LLVM to parse this YAML file, the code supports and
asserts that we're writing only.
On the other hand, I did experiment that the class hierarchy starting at
DiagnosticInfoOptimizationBase can be mapped back from YAML generated
here (see D24479).
* The YAML stream is stored in the LLVM context.
* In the example, we can probably further specify the IR value used,
i.e. print "Function" rather than "Value".
* As before hotness is computed in the analysis pass instead of
DiganosticInfo. This avoids the layering problem since BFI is in
Analysis while DiagnosticInfo is in IR.
[1] https://reviews.llvm.org/D19678#419445
Differential Revision: https://reviews.llvm.org/D24587
llvm-svn: 282539
2016-09-28 04:55:07 +08:00
|
|
|
OS << Arg.Val;
|
|
|
|
return OS.str();
|
|
|
|
}
|