2013-12-17 18:47:22 +01:00
|
|
|
//===- llvm/Support/DiagnosticInfo.cpp - Diagnostic Definitions -*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2013-12-17 18:47:22 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines the different classes involved in low level diagnostics.
|
|
|
|
//
|
|
|
|
// Diagnostics reporting is still done as part of the LLVMContext.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-06-06 13:49:48 +02:00
|
|
|
#include "llvm/IR/DiagnosticInfo.h"
|
2017-09-15 22:10:09 +02: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-27 22:55:07 +02:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2013-12-17 18:47:22 +01:00
|
|
|
#include "llvm/ADT/Twine.h"
|
2017-06-06 13:49:48 +02:00
|
|
|
#include "llvm/ADT/iterator_range.h"
|
2017-05-15 23:57:41 +02:00
|
|
|
#include "llvm/IR/BasicBlock.h"
|
2013-12-17 18:47:22 +01:00
|
|
|
#include "llvm/IR/Constants.h"
|
2017-05-15 23:57:41 +02:00
|
|
|
#include "llvm/IR/DebugInfoMetadata.h"
|
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
2013-12-17 18:47:22 +01:00
|
|
|
#include "llvm/IR/DiagnosticPrinter.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
2017-05-15 23:57:41 +02:00
|
|
|
#include "llvm/IR/GlobalValue.h"
|
2013-12-17 18:47:22 +01:00
|
|
|
#include "llvm/IR/Instruction.h"
|
2017-05-15 23:57:41 +02:00
|
|
|
#include "llvm/IR/LLVMContext.h"
|
2013-12-17 18:47:22 +01:00
|
|
|
#include "llvm/IR/Metadata.h"
|
2014-04-08 18:42:34 +02:00
|
|
|
#include "llvm/IR/Module.h"
|
2017-05-15 23:57:41 +02:00
|
|
|
#include "llvm/IR/Type.h"
|
|
|
|
#include "llvm/IR/Value.h"
|
|
|
|
#include "llvm/Support/Casting.h"
|
2014-05-22 19:19:01 +02:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2017-05-15 23:57:41 +02:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2018-12-06 19:44:48 +01:00
|
|
|
#include "llvm/Support/Path.h"
|
2014-05-22 19:19:01 +02:00
|
|
|
#include "llvm/Support/Regex.h"
|
2018-12-04 17:30:31 +01:00
|
|
|
#include "llvm/Support/ScopedPrinter.h"
|
2018-12-06 19:44:48 +01:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2015-06-11 19:30:34 +02:00
|
|
|
#include <atomic>
|
2017-05-15 23:57:41 +02:00
|
|
|
#include <cassert>
|
|
|
|
#include <memory>
|
2013-12-17 18:47:22 +01:00
|
|
|
#include <string>
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2013-12-18 11:12:06 +01:00
|
|
|
int llvm::getNextAvailablePluginDiagnosticKind() {
|
2015-06-11 19:30:34 +02:00
|
|
|
static std::atomic<int> PluginKindID(DK_FirstPluginKind);
|
|
|
|
return ++PluginKindID;
|
2013-12-17 18:47:22 +01:00
|
|
|
}
|
|
|
|
|
2016-09-28 00:19:23 +02:00
|
|
|
const char *OptimizationRemarkAnalysis::AlwaysPrint = "";
|
2015-08-11 03:09:15 +02:00
|
|
|
|
2013-12-17 18:47:22 +01:00
|
|
|
DiagnosticInfoInlineAsm::DiagnosticInfoInlineAsm(const Instruction &I,
|
|
|
|
const Twine &MsgStr,
|
|
|
|
DiagnosticSeverity Severity)
|
2017-05-15 23:57:41 +02:00
|
|
|
: DiagnosticInfo(DK_InlineAsm, Severity), MsgStr(MsgStr), Instr(&I) {
|
2014-11-11 22:30:22 +01:00
|
|
|
if (const MDNode *SrcLoc = I.getMetadata("srcloc")) {
|
2013-12-17 18:47:22 +01: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-09 19:38:53 +01:00
|
|
|
if (const auto *CI =
|
|
|
|
mdconst::dyn_extract<ConstantInt>(SrcLoc->getOperand(0)))
|
2013-12-17 18:47:22 +01:00
|
|
|
LocCookie = CI->getZExtValue();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void DiagnosticInfoInlineAsm::print(DiagnosticPrinter &DP) const {
|
|
|
|
DP << getMsgStr();
|
|
|
|
if (getLocCookie())
|
|
|
|
DP << " at line " << getLocCookie();
|
|
|
|
}
|
|
|
|
|
2016-06-20 20:13:04 +02:00
|
|
|
void DiagnosticInfoResourceLimit::print(DiagnosticPrinter &DP) const {
|
|
|
|
DP << getResourceName() << " limit";
|
|
|
|
|
|
|
|
if (getResourceLimit() != 0)
|
|
|
|
DP << " of " << getResourceLimit();
|
|
|
|
|
|
|
|
DP << " exceeded (" << getResourceSize() << ") in " << getFunction();
|
2013-12-17 18:47:22 +01:00
|
|
|
}
|
2014-01-16 02:51:12 +01:00
|
|
|
|
|
|
|
void DiagnosticInfoDebugMetadataVersion::print(DiagnosticPrinter &DP) const {
|
2014-02-05 00:49:02 +01:00
|
|
|
DP << "ignoring debug info with an invalid version (" << getMetadataVersion()
|
|
|
|
<< ") in " << getModule();
|
2014-01-16 02:51:12 +01:00
|
|
|
}
|
2014-03-14 22:58:59 +01:00
|
|
|
|
2016-05-09 21:57:29 +02:00
|
|
|
void DiagnosticInfoIgnoringInvalidDebugMetadata::print(
|
|
|
|
DiagnosticPrinter &DP) const {
|
|
|
|
DP << "ignoring invalid debug info in " << getModule().getModuleIdentifier();
|
|
|
|
}
|
|
|
|
|
2014-03-14 22:58:59 +01:00
|
|
|
void DiagnosticInfoSampleProfile::print(DiagnosticPrinter &DP) const {
|
2015-11-02 21:01:13 +01:00
|
|
|
if (!FileName.empty()) {
|
|
|
|
DP << getFileName();
|
|
|
|
if (LineNum > 0)
|
|
|
|
DP << ":" << getLineNum();
|
|
|
|
DP << ": ";
|
|
|
|
}
|
2014-03-14 22:58:59 +01:00
|
|
|
DP << getMsg();
|
|
|
|
}
|
2014-04-08 18:42:34 +02:00
|
|
|
|
2015-12-09 19:08:16 +01:00
|
|
|
void DiagnosticInfoPGOProfile::print(DiagnosticPrinter &DP) const {
|
|
|
|
if (getFileName())
|
|
|
|
DP << getFileName() << ": ";
|
|
|
|
DP << getMsg();
|
|
|
|
}
|
|
|
|
|
2018-12-29 03:02:13 +01:00
|
|
|
void DiagnosticInfo::anchor() {}
|
|
|
|
void DiagnosticInfoStackSize::anchor() {}
|
|
|
|
void DiagnosticInfoWithLocationBase::anchor() {}
|
|
|
|
void DiagnosticInfoIROptimization::anchor() {}
|
|
|
|
|
2017-02-18 01:42:23 +01:00
|
|
|
DiagnosticLocation::DiagnosticLocation(const DebugLoc &DL) {
|
|
|
|
if (!DL)
|
|
|
|
return;
|
2018-12-06 19:44:48 +01:00
|
|
|
File = DL->getFile();
|
2017-02-18 01:42:23 +01:00
|
|
|
Line = DL->getLine();
|
|
|
|
Column = DL->getColumn();
|
2014-04-08 18:42:34 +02:00
|
|
|
}
|
|
|
|
|
2017-02-18 03:00:27 +01:00
|
|
|
DiagnosticLocation::DiagnosticLocation(const DISubprogram *SP) {
|
|
|
|
if (!SP)
|
|
|
|
return;
|
2018-12-06 19:44:48 +01:00
|
|
|
|
|
|
|
File = SP->getFile();
|
2017-02-18 03:00:27 +01:00
|
|
|
Line = SP->getScopeLine();
|
|
|
|
Column = 0;
|
|
|
|
}
|
|
|
|
|
2018-12-06 19:44:48 +01:00
|
|
|
StringRef DiagnosticLocation::getRelativePath() const {
|
|
|
|
return File->getFilename();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string DiagnosticLocation::getAbsolutePath() const {
|
|
|
|
StringRef Name = File->getFilename();
|
|
|
|
if (sys::path::is_absolute(Name))
|
|
|
|
return Name;
|
|
|
|
|
|
|
|
SmallString<128> Path;
|
|
|
|
sys::path::append(Path, File->getDirectory(), Name);
|
|
|
|
return sys::path::remove_leading_dotslash(Path).str();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string DiagnosticInfoWithLocationBase::getAbsolutePath() const {
|
|
|
|
return Loc.getAbsolutePath();
|
|
|
|
}
|
|
|
|
|
|
|
|
void DiagnosticInfoWithLocationBase::getLocation(StringRef &RelativePath,
|
|
|
|
unsigned &Line,
|
|
|
|
unsigned &Column) const {
|
|
|
|
RelativePath = Loc.getRelativePath();
|
|
|
|
Line = Loc.getLine();
|
|
|
|
Column = Loc.getColumn();
|
2014-04-08 18:42:34 +02:00
|
|
|
}
|
|
|
|
|
2017-02-17 18:34:37 +01:00
|
|
|
const std::string DiagnosticInfoWithLocationBase::getLocationStr() const {
|
2014-04-08 18:42:34 +02:00
|
|
|
StringRef Filename("<unknown>");
|
|
|
|
unsigned Line = 0;
|
|
|
|
unsigned Column = 0;
|
|
|
|
if (isLocationAvailable())
|
2018-12-06 19:44:48 +01:00
|
|
|
getLocation(Filename, Line, Column);
|
2015-03-30 17:42:36 +02:00
|
|
|
return (Filename + ":" + Twine(Line) + ":" + Twine(Column)).str();
|
2014-04-08 18:42:34 +02:00
|
|
|
}
|
2016-12-01 18:34:44 +01:00
|
|
|
|
2017-02-15 21:38:28 +01:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, const Value *V)
|
2016-12-01 18:34:44 +01:00
|
|
|
: Key(Key) {
|
2016-11-07 23:41:13 +01:00
|
|
|
if (auto *F = dyn_cast<Function>(V)) {
|
|
|
|
if (DISubprogram *SP = F->getSubprogram())
|
2017-02-18 03:00:27 +01:00
|
|
|
Loc = SP;
|
2016-11-07 23:41:13 +01:00
|
|
|
}
|
|
|
|
else if (auto *I = dyn_cast<Instruction>(V))
|
2017-02-18 01:42:23 +01:00
|
|
|
Loc = I->getDebugLoc();
|
2016-12-01 18:34:44 +01:00
|
|
|
|
2018-01-09 18:52:00 +01:00
|
|
|
// Only include names that correspond to user variables. FIXME: We should use
|
2016-12-01 18:34:44 +01:00
|
|
|
// debug info if available to get the name of the user variable.
|
|
|
|
if (isa<llvm::Argument>(V) || isa<GlobalValue>(V))
|
2017-05-16 02:39:01 +02:00
|
|
|
Val = GlobalValue::dropLLVMManglingEscape(V->getName());
|
2016-12-01 18:34:44 +01:00
|
|
|
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-07 23:41:13 +01:00
|
|
|
}
|
2014-04-08 18:42:34 +02:00
|
|
|
|
2017-02-15 21:38:28 +01:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, const Type *T)
|
2016-12-01 17:40:32 +01:00
|
|
|
: Key(Key) {
|
|
|
|
raw_string_ostream OS(Val);
|
|
|
|
OS << *T;
|
|
|
|
}
|
|
|
|
|
2017-07-30 02:35:33 +02:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, StringRef S)
|
|
|
|
: Key(Key), Val(S.str()) {}
|
|
|
|
|
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-27 22:55:07 +02:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, int N)
|
|
|
|
: Key(Key), Val(itostr(N)) {}
|
|
|
|
|
2018-01-23 10:47:28 +01:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, float N)
|
|
|
|
: Key(Key), Val(llvm::to_string(N)) {}
|
|
|
|
|
2017-08-24 06:04:49 +02:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, long N)
|
|
|
|
: Key(Key), Val(itostr(N)) {}
|
|
|
|
|
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, long long N)
|
2017-07-27 18:54:13 +02:00
|
|
|
: Key(Key), Val(itostr(N)) {}
|
|
|
|
|
2016-09-29 18:23:12 +02:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, unsigned N)
|
|
|
|
: Key(Key), Val(utostr(N)) {}
|
|
|
|
|
2017-08-24 06:04:49 +02:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key,
|
|
|
|
unsigned long N)
|
|
|
|
: Key(Key), Val(utostr(N)) {}
|
|
|
|
|
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key,
|
|
|
|
unsigned long long N)
|
2017-07-27 18:54:13 +02:00
|
|
|
: Key(Key), Val(utostr(N)) {}
|
|
|
|
|
2017-08-11 23:12:04 +02:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, DebugLoc Loc)
|
|
|
|
: Key(Key), Loc(Loc) {
|
|
|
|
if (Loc) {
|
|
|
|
Val = (Loc->getFilename() + ":" + Twine(Loc.getLine()) + ":" +
|
|
|
|
Twine(Loc.getCol())).str();
|
|
|
|
} else {
|
|
|
|
Val = "<UNKNOWN LOCATION>";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-16 02:36:00 +02:00
|
|
|
void DiagnosticInfoOptimizationBase::print(DiagnosticPrinter &DP) const {
|
2014-04-08 18:42:34 +02:00
|
|
|
DP << getLocationStr() << ": " << getMsg();
|
2016-07-15 19:23:20 +02:00
|
|
|
if (Hotness)
|
|
|
|
DP << " (hotness: " << *Hotness << ")";
|
2014-04-08 18:42:34 +02:00
|
|
|
}
|
2014-05-22 16:19:46 +02:00
|
|
|
|
2016-09-28 01:47:03 +02:00
|
|
|
OptimizationRemark::OptimizationRemark(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
2017-02-18 01:42:23 +01:00
|
|
|
const DiagnosticLocation &Loc,
|
2017-02-22 08:38:17 +01:00
|
|
|
const Value *CodeRegion)
|
2017-01-26 00:20:25 +01:00
|
|
|
: DiagnosticInfoIROptimization(
|
2016-09-28 01:47:03 +02:00
|
|
|
DK_OptimizationRemark, DS_Remark, PassName, RemarkName,
|
2017-02-18 01:42:23 +01:00
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), Loc, CodeRegion) {}
|
2016-09-28 01:47:03 +02:00
|
|
|
|
2016-09-30 02:42:43 +02:00
|
|
|
OptimizationRemark::OptimizationRemark(const char *PassName,
|
2017-02-28 17:02:37 +01:00
|
|
|
StringRef RemarkName,
|
|
|
|
const Instruction *Inst)
|
2017-01-26 00:20:25 +01:00
|
|
|
: DiagnosticInfoIROptimization(DK_OptimizationRemark, DS_Remark, PassName,
|
|
|
|
RemarkName, *Inst->getParent()->getParent(),
|
|
|
|
Inst->getDebugLoc(), Inst->getParent()) {}
|
2016-09-30 02:42:43 +02:00
|
|
|
|
2017-02-28 17:02:37 +01:00
|
|
|
// Helper to allow for an assert before attempting to return an invalid
|
|
|
|
// reference.
|
|
|
|
static const BasicBlock &getFirstFunctionBlock(const Function *Func) {
|
|
|
|
assert(!Func->empty() && "Function does not have a body");
|
|
|
|
return Func->front();
|
|
|
|
}
|
|
|
|
|
|
|
|
OptimizationRemark::OptimizationRemark(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
|
|
|
const Function *Func)
|
|
|
|
: DiagnosticInfoIROptimization(DK_OptimizationRemark, DS_Remark, PassName,
|
|
|
|
RemarkName, *Func, Func->getSubprogram(),
|
|
|
|
&getFirstFunctionBlock(Func)) {}
|
|
|
|
|
2017-09-15 22:10:09 +02:00
|
|
|
bool OptimizationRemark::isEnabled() const {
|
|
|
|
const Function &Fn = getFunction();
|
|
|
|
LLVMContext &Ctx = Fn.getContext();
|
|
|
|
return Ctx.getDiagHandlerPtr()->isPassedOptRemarkEnabled(getPassName());
|
2014-05-22 16:19:46 +02:00
|
|
|
}
|
|
|
|
|
2017-02-18 01:42:23 +01:00
|
|
|
OptimizationRemarkMissed::OptimizationRemarkMissed(
|
|
|
|
const char *PassName, StringRef RemarkName, const DiagnosticLocation &Loc,
|
2017-02-23 20:17:34 +01:00
|
|
|
const Value *CodeRegion)
|
2017-01-26 00:20:25 +01:00
|
|
|
: DiagnosticInfoIROptimization(
|
2016-09-28 01:47:03 +02:00
|
|
|
DK_OptimizationRemarkMissed, DS_Remark, PassName, RemarkName,
|
2017-02-18 01:42:23 +01:00
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), Loc, CodeRegion) {}
|
2016-09-28 01:47:03 +02:00
|
|
|
|
2016-09-28 00:19:23 +02:00
|
|
|
OptimizationRemarkMissed::OptimizationRemarkMissed(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
2017-02-23 20:17:34 +01:00
|
|
|
const Instruction *Inst)
|
2017-01-26 00:20:25 +01:00
|
|
|
: DiagnosticInfoIROptimization(DK_OptimizationRemarkMissed, DS_Remark,
|
|
|
|
PassName, RemarkName,
|
|
|
|
*Inst->getParent()->getParent(),
|
|
|
|
Inst->getDebugLoc(), Inst->getParent()) {}
|
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-27 22:55:07 +02:00
|
|
|
|
2017-09-15 22:10:09 +02:00
|
|
|
bool OptimizationRemarkMissed::isEnabled() const {
|
|
|
|
const Function &Fn = getFunction();
|
|
|
|
LLVMContext &Ctx = Fn.getContext();
|
|
|
|
return Ctx.getDiagHandlerPtr()->isMissedOptRemarkEnabled(getPassName());
|
2014-05-22 16:19:46 +02:00
|
|
|
}
|
|
|
|
|
2017-02-18 01:42:23 +01:00
|
|
|
OptimizationRemarkAnalysis::OptimizationRemarkAnalysis(
|
|
|
|
const char *PassName, StringRef RemarkName, const DiagnosticLocation &Loc,
|
2017-02-23 20:17:34 +01:00
|
|
|
const Value *CodeRegion)
|
2017-01-26 00:20:25 +01:00
|
|
|
: DiagnosticInfoIROptimization(
|
2016-09-29 18:23:12 +02:00
|
|
|
DK_OptimizationRemarkAnalysis, DS_Remark, PassName, RemarkName,
|
2017-02-18 01:42:23 +01:00
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), Loc, CodeRegion) {}
|
2016-09-29 18:23:12 +02:00
|
|
|
|
2016-09-28 01:47:03 +02:00
|
|
|
OptimizationRemarkAnalysis::OptimizationRemarkAnalysis(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
2017-02-23 20:17:34 +01:00
|
|
|
const Instruction *Inst)
|
2017-01-26 00:20:25 +01:00
|
|
|
: DiagnosticInfoIROptimization(DK_OptimizationRemarkAnalysis, DS_Remark,
|
|
|
|
PassName, RemarkName,
|
|
|
|
*Inst->getParent()->getParent(),
|
|
|
|
Inst->getDebugLoc(), Inst->getParent()) {}
|
2016-09-28 01:47:03 +02:00
|
|
|
|
2017-02-18 01:42:23 +01:00
|
|
|
OptimizationRemarkAnalysis::OptimizationRemarkAnalysis(
|
|
|
|
enum DiagnosticKind Kind, const char *PassName, StringRef RemarkName,
|
2017-02-23 20:17:34 +01:00
|
|
|
const DiagnosticLocation &Loc, const Value *CodeRegion)
|
2017-01-26 00:20:25 +01:00
|
|
|
: DiagnosticInfoIROptimization(Kind, DS_Remark, PassName, RemarkName,
|
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(),
|
2017-02-18 01:42:23 +01:00
|
|
|
Loc, CodeRegion) {}
|
2016-09-29 20:04:47 +02:00
|
|
|
|
2017-09-15 22:10:09 +02:00
|
|
|
bool OptimizationRemarkAnalysis::isEnabled() const {
|
|
|
|
const Function &Fn = getFunction();
|
|
|
|
LLVMContext &Ctx = Fn.getContext();
|
|
|
|
return Ctx.getDiagHandlerPtr()->isAnalysisRemarkEnabled(getPassName()) ||
|
|
|
|
shouldAlwaysPrint();
|
2014-05-22 16:19:46 +02:00
|
|
|
}
|
|
|
|
|
2015-06-15 22:30:22 +02:00
|
|
|
void DiagnosticInfoMIRParser::print(DiagnosticPrinter &DP) const {
|
|
|
|
DP << Diagnostic;
|
|
|
|
}
|
|
|
|
|
2017-02-02 06:41:51 +01:00
|
|
|
DiagnosticInfoOptimizationFailure::DiagnosticInfoOptimizationFailure(
|
2017-02-18 01:42:23 +01:00
|
|
|
const char *PassName, StringRef RemarkName, const DiagnosticLocation &Loc,
|
2017-02-23 20:17:34 +01:00
|
|
|
const Value *CodeRegion)
|
2017-02-02 06:41:51 +01:00
|
|
|
: DiagnosticInfoIROptimization(
|
|
|
|
DK_OptimizationFailure, DS_Warning, PassName, RemarkName,
|
2017-02-18 01:42:23 +01:00
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), Loc, CodeRegion) {}
|
2017-02-02 06:41:51 +01:00
|
|
|
|
2014-07-18 21:36:04 +02:00
|
|
|
bool DiagnosticInfoOptimizationFailure::isEnabled() const {
|
2014-07-16 02:36:00 +02:00
|
|
|
// Only print warnings.
|
|
|
|
return getSeverity() == DS_Warning;
|
|
|
|
}
|
|
|
|
|
2016-02-02 14:52:43 +01: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;
|
|
|
|
}
|
|
|
|
|
2016-08-31 20:42:55 +02: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-27 22:55:07 +02:00
|
|
|
|
2017-09-20 01:00:55 +02:00
|
|
|
void DiagnosticInfoOptimizationBase::insert(StringRef S) {
|
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-27 22:55:07 +02:00
|
|
|
Args.emplace_back(S);
|
|
|
|
}
|
|
|
|
|
2017-09-20 01:00:55 +02:00
|
|
|
void DiagnosticInfoOptimizationBase::insert(Argument A) {
|
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-27 22:55:07 +02:00
|
|
|
Args.push_back(std::move(A));
|
|
|
|
}
|
|
|
|
|
2017-09-20 01:00:55 +02:00
|
|
|
void DiagnosticInfoOptimizationBase::insert(setIsVerbose V) {
|
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-27 22:55:07 +02:00
|
|
|
IsVerbose = true;
|
|
|
|
}
|
|
|
|
|
2017-09-20 01:00:55 +02:00
|
|
|
void DiagnosticInfoOptimizationBase::insert(setExtraArgs EA) {
|
2016-12-01 18:34:44 +01:00
|
|
|
FirstExtraArgIndex = Args.size();
|
|
|
|
}
|
|
|
|
|
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-27 22:55:07 +02:00
|
|
|
std::string DiagnosticInfoOptimizationBase::getMsg() const {
|
|
|
|
std::string Str;
|
|
|
|
raw_string_ostream OS(Str);
|
2016-12-01 18:34:44 +01: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-27 22:55:07 +02:00
|
|
|
OS << Arg.Val;
|
|
|
|
return OS.str();
|
|
|
|
}
|
2017-10-04 17:18:11 +02:00
|
|
|
|
2018-12-29 03:02:13 +01:00
|
|
|
void OptimizationRemarkAnalysisFPCommute::anchor() {}
|
|
|
|
void OptimizationRemarkAnalysisAliasing::anchor() {}
|