2013-12-18 01:47:22 +08:00
|
|
|
//===- llvm/Support/DiagnosticInfo.cpp - Diagnostic Definitions -*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08: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-18 01:47:22 +08: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 19:49:48 +08:00
|
|
|
#include "llvm/IR/DiagnosticInfo.h"
|
2017-09-16 04:10:09 +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"
|
2017-06-06 19:49:48 +08:00
|
|
|
#include "llvm/ADT/iterator_range.h"
|
2017-05-16 05:57:41 +08:00
|
|
|
#include "llvm/IR/BasicBlock.h"
|
2013-12-18 01:47:22 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
2017-05-16 05:57:41 +08:00
|
|
|
#include "llvm/IR/DebugInfoMetadata.h"
|
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
2013-12-18 01:47:22 +08:00
|
|
|
#include "llvm/IR/DiagnosticPrinter.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
2017-05-16 05:57:41 +08:00
|
|
|
#include "llvm/IR/GlobalValue.h"
|
2013-12-18 01:47:22 +08:00
|
|
|
#include "llvm/IR/Instruction.h"
|
2017-05-16 05:57:41 +08:00
|
|
|
#include "llvm/IR/LLVMContext.h"
|
2013-12-18 01:47:22 +08:00
|
|
|
#include "llvm/IR/Metadata.h"
|
2014-04-09 00:42:34 +08:00
|
|
|
#include "llvm/IR/Module.h"
|
2017-05-16 05:57:41 +08:00
|
|
|
#include "llvm/IR/Type.h"
|
|
|
|
#include "llvm/IR/Value.h"
|
|
|
|
#include "llvm/Support/Casting.h"
|
2014-05-23 01:19:01 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2017-05-16 05:57:41 +08:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2020-11-10 19:09:20 +08:00
|
|
|
#include "llvm/Support/InstructionCost.h"
|
2018-12-07 02:44:48 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2014-05-23 01:19:01 +08:00
|
|
|
#include "llvm/Support/Regex.h"
|
2018-12-05 00:30:31 +08:00
|
|
|
#include "llvm/Support/ScopedPrinter.h"
|
2018-12-07 02:44:48 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2015-06-12 01:30:34 +08:00
|
|
|
#include <atomic>
|
2017-05-16 05:57:41 +08:00
|
|
|
#include <cassert>
|
|
|
|
#include <memory>
|
2013-12-18 01:47:22 +08:00
|
|
|
#include <string>
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
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)
|
2017-05-16 05:57:41 +08:00
|
|
|
: DiagnosticInfo(DK_InlineAsm, Severity), 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();
|
|
|
|
}
|
|
|
|
|
2018-12-29 10:02:13 +08:00
|
|
|
void DiagnosticInfo::anchor() {}
|
|
|
|
void DiagnosticInfoStackSize::anchor() {}
|
|
|
|
void DiagnosticInfoWithLocationBase::anchor() {}
|
|
|
|
void DiagnosticInfoIROptimization::anchor() {}
|
|
|
|
|
2017-02-18 08:42:23 +08:00
|
|
|
DiagnosticLocation::DiagnosticLocation(const DebugLoc &DL) {
|
|
|
|
if (!DL)
|
|
|
|
return;
|
2018-12-07 02:44:48 +08:00
|
|
|
File = DL->getFile();
|
2017-02-18 08:42:23 +08:00
|
|
|
Line = DL->getLine();
|
|
|
|
Column = DL->getColumn();
|
2014-04-09 00:42:34 +08:00
|
|
|
}
|
|
|
|
|
2017-02-18 10:00:27 +08:00
|
|
|
DiagnosticLocation::DiagnosticLocation(const DISubprogram *SP) {
|
|
|
|
if (!SP)
|
|
|
|
return;
|
2020-02-18 10:48:38 +08:00
|
|
|
|
2018-12-07 02:44:48 +08:00
|
|
|
File = SP->getFile();
|
2017-02-18 10:00:27 +08:00
|
|
|
Line = SP->getScopeLine();
|
|
|
|
Column = 0;
|
|
|
|
}
|
|
|
|
|
2018-12-07 02:44:48 +08:00
|
|
|
StringRef DiagnosticLocation::getRelativePath() const {
|
|
|
|
return File->getFilename();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string DiagnosticLocation::getAbsolutePath() const {
|
|
|
|
StringRef Name = File->getFilename();
|
|
|
|
if (sys::path::is_absolute(Name))
|
2020-01-29 03:23:46 +08:00
|
|
|
return std::string(Name);
|
2018-12-07 02:44:48 +08:00
|
|
|
|
|
|
|
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-09 00:42:34 +08:00
|
|
|
}
|
|
|
|
|
2017-02-18 01:34:37 +08:00
|
|
|
const std::string DiagnosticInfoWithLocationBase::getLocationStr() const {
|
2014-04-09 00:42:34 +08:00
|
|
|
StringRef Filename("<unknown>");
|
|
|
|
unsigned Line = 0;
|
|
|
|
unsigned Column = 0;
|
|
|
|
if (isLocationAvailable())
|
2018-12-07 02:44:48 +08:00
|
|
|
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
|
|
|
|
2020-01-29 03:23:46 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key,
|
|
|
|
const Value *V)
|
|
|
|
: Key(std::string(Key)) {
|
2016-11-08 06:41:13 +08:00
|
|
|
if (auto *F = dyn_cast<Function>(V)) {
|
|
|
|
if (DISubprogram *SP = F->getSubprogram())
|
2017-02-18 10:00:27 +08:00
|
|
|
Loc = SP;
|
2016-11-08 06:41:13 +08:00
|
|
|
}
|
|
|
|
else if (auto *I = dyn_cast<Instruction>(V))
|
2017-02-18 08:42:23 +08:00
|
|
|
Loc = I->getDebugLoc();
|
2016-12-02 01:34:44 +08:00
|
|
|
|
2018-01-10 01:52:00 +08:00
|
|
|
// Only include names that correspond to user variables. FIXME: We should use
|
2016-12-02 01:34:44 +08:00
|
|
|
// debug info if available to get the name of the user variable.
|
|
|
|
if (isa<llvm::Argument>(V) || isa<GlobalValue>(V))
|
2020-01-29 03:23:46 +08:00
|
|
|
Val = std::string(GlobalValue::dropLLVMManglingEscape(V->getName()));
|
2016-12-02 01:34:44 +08: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-08 06:41:13 +08:00
|
|
|
}
|
2014-04-09 00:42:34 +08:00
|
|
|
|
2017-02-16 04:38:28 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, const Type *T)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Key(std::string(Key)) {
|
2016-12-02 00:40:32 +08:00
|
|
|
raw_string_ostream OS(Val);
|
|
|
|
OS << *T;
|
|
|
|
}
|
|
|
|
|
2017-07-30 08:35:33 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, StringRef S)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Key(std::string(Key)), Val(S.str()) {}
|
2017-07-30 08:35:33 +08:00
|
|
|
|
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)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Key(std::string(Key)), Val(itostr(N)) {}
|
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
|
|
|
|
2018-01-23 17:47:28 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, float N)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Key(std::string(Key)), Val(llvm::to_string(N)) {}
|
2018-01-23 17:47:28 +08:00
|
|
|
|
2017-08-24 12:04:49 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, long N)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Key(std::string(Key)), Val(itostr(N)) {}
|
2017-08-24 12:04:49 +08:00
|
|
|
|
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, long long N)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Key(std::string(Key)), Val(itostr(N)) {}
|
2017-07-28 00:54:13 +08:00
|
|
|
|
2016-09-30 00:23:12 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, unsigned N)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Key(std::string(Key)), Val(utostr(N)) {}
|
2016-09-30 00:23:12 +08:00
|
|
|
|
2017-08-24 12:04:49 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key,
|
|
|
|
unsigned long N)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Key(std::string(Key)), Val(utostr(N)) {}
|
2017-08-24 12:04:49 +08:00
|
|
|
|
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key,
|
|
|
|
unsigned long long N)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Key(std::string(Key)), Val(utostr(N)) {}
|
2017-07-28 00:54:13 +08:00
|
|
|
|
[llvm][LV] Replace `unsigned VF` with `ElementCount VF` [NFCI]
Changes:
* Change `ToVectorTy` to deal directly with `ElementCount` instances.
* `VF == 1` replaced with `VF.isScalar()`.
* `VF > 1` and `VF >=2` replaced with `VF.isVector()`.
* `VF <=1` is replaced with `VF.isZero() || VF.isScalar()`.
* Replaced the uses of `llvm::SmallSet<ElementCount, ...>` with
`llvm::SmallSetVector<ElementCount, ...>`. This avoids the need of an
ordering function for the `ElementCount` class.
* Bits and pieces around printing the `ElementCount` to string streams.
To guarantee that this change is a NFC, `VF.Min` and asserts are used
in the following places:
1. When it doesn't make sense to deal with the scalable property, for
example:
a. When computing unrolling factors.
b. When shuffle masks are built for fixed width vector types
In this cases, an
assert(!VF.Scalable && "<mgs>") has been added to make sure we don't
enter coepaths that don't make sense for scalable vectors.
2. When there is a conscious decision to use `FixedVectorType`. These
uses of `FixedVectorType` will likely be removed in favour of
`VectorType` once the vectorizer is generic enough to deal with both
fixed vector types and scalable vector types.
3. When dealing with building constants out of the value of VF, for
example when computing the vectorization `step`, or building vectors
of indices. These operation _make sense_ for scalable vectors too,
but changing the code in these places to be generic and make it work
for scalable vectors is to be submitted in a separate patch, as it is
a functional change.
4. When building the potential VFs in VPlan. Making the VPlan generic
enough to handle scalable vectorization factors is a functional change
that needs a separate patch. See for example `void
LoopVectorizationPlanner::buildVPlans(unsigned MinVF, unsigned
MaxVF)`.
5. The class `IntrinsicCostAttribute`: this class still uses `unsigned
VF` as updating the field to use `ElementCount` woudl require changes
that could result in changing the behavior of the compiler. Will be done
in a separate patch.
7. When dealing with user input for forcing the vectorization
factor. In this case, adding support for scalable vectorization is a
functional change that migh require changes at command line.
Note that in some places the idiom
```
unsigned VF = ...
auto VTy = FixedVectorType::get(ScalarTy, VF)
```
has been replaced with
```
ElementCount VF = ...
assert(!VF.Scalable && ...);
auto VTy = VectorType::get(ScalarTy, VF)
```
The assertion guarantees that the new code is (at least in debug mode)
functionally equivalent to the old version. Notice that this change had been
possible because none of the methods that are specific to `FixedVectorType`
were used after the instantiation of `VTy`.
Reviewed By: rengolin, ctetreau
Differential Revision: https://reviews.llvm.org/D85794
2020-08-08 06:03:24 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key,
|
|
|
|
ElementCount EC)
|
|
|
|
: Key(std::string(Key)) {
|
|
|
|
raw_string_ostream OS(Val);
|
|
|
|
EC.print(OS);
|
|
|
|
}
|
|
|
|
|
2020-11-10 19:09:20 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key,
|
|
|
|
InstructionCost C)
|
|
|
|
: Key(std::string(Key)) {
|
|
|
|
raw_string_ostream OS(Val);
|
|
|
|
C.print(OS);
|
|
|
|
}
|
|
|
|
|
2017-08-12 05:12:04 +08:00
|
|
|
DiagnosticInfoOptimizationBase::Argument::Argument(StringRef Key, DebugLoc Loc)
|
2020-01-29 03:23:46 +08:00
|
|
|
: Key(std::string(Key)), Loc(Loc) {
|
2017-08-12 05:12:04 +08:00
|
|
|
if (Loc) {
|
|
|
|
Val = (Loc->getFilename() + ":" + Twine(Loc.getLine()) + ":" +
|
|
|
|
Twine(Loc.getCol())).str();
|
|
|
|
} else {
|
|
|
|
Val = "<UNKNOWN LOCATION>";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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,
|
2017-02-18 08:42:23 +08:00
|
|
|
const DiagnosticLocation &Loc,
|
2017-02-22 15:38:17 +08:00
|
|
|
const Value *CodeRegion)
|
2017-01-26 07:20:25 +08:00
|
|
|
: DiagnosticInfoIROptimization(
|
2016-09-28 07:47:03 +08:00
|
|
|
DK_OptimizationRemark, DS_Remark, PassName, RemarkName,
|
2017-02-18 08:42:23 +08:00
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), Loc, CodeRegion) {}
|
2016-09-28 07:47:03 +08:00
|
|
|
|
2016-09-30 08:42:43 +08:00
|
|
|
OptimizationRemark::OptimizationRemark(const char *PassName,
|
2017-03-01 00:02:37 +08:00
|
|
|
StringRef RemarkName,
|
|
|
|
const Instruction *Inst)
|
2017-01-26 07:20:25 +08:00
|
|
|
: DiagnosticInfoIROptimization(DK_OptimizationRemark, DS_Remark, PassName,
|
|
|
|
RemarkName, *Inst->getParent()->getParent(),
|
|
|
|
Inst->getDebugLoc(), Inst->getParent()) {}
|
2016-09-30 08:42:43 +08:00
|
|
|
|
2020-01-29 09:13:12 +08:00
|
|
|
static const BasicBlock *getFirstFunctionBlock(const Function *Func) {
|
|
|
|
return Func->empty() ? nullptr : &Func->front();
|
2017-03-01 00:02:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
OptimizationRemark::OptimizationRemark(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
|
|
|
const Function *Func)
|
|
|
|
: DiagnosticInfoIROptimization(DK_OptimizationRemark, DS_Remark, PassName,
|
|
|
|
RemarkName, *Func, Func->getSubprogram(),
|
2020-01-29 09:13:12 +08:00
|
|
|
getFirstFunctionBlock(Func)) {}
|
2017-03-01 00:02:37 +08:00
|
|
|
|
2017-09-16 04:10:09 +08:00
|
|
|
bool OptimizationRemark::isEnabled() const {
|
|
|
|
const Function &Fn = getFunction();
|
|
|
|
LLVMContext &Ctx = Fn.getContext();
|
|
|
|
return Ctx.getDiagHandlerPtr()->isPassedOptRemarkEnabled(getPassName());
|
2014-05-22 22:19:46 +08:00
|
|
|
}
|
|
|
|
|
2017-02-18 08:42:23 +08:00
|
|
|
OptimizationRemarkMissed::OptimizationRemarkMissed(
|
|
|
|
const char *PassName, StringRef RemarkName, const DiagnosticLocation &Loc,
|
2017-02-24 03:17:34 +08:00
|
|
|
const Value *CodeRegion)
|
2017-01-26 07:20:25 +08:00
|
|
|
: DiagnosticInfoIROptimization(
|
2016-09-28 07:47:03 +08:00
|
|
|
DK_OptimizationRemarkMissed, DS_Remark, PassName, RemarkName,
|
2017-02-18 08:42:23 +08:00
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), Loc, CodeRegion) {}
|
2016-09-28 07:47:03 +08:00
|
|
|
|
2016-09-28 06:19:23 +08:00
|
|
|
OptimizationRemarkMissed::OptimizationRemarkMissed(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
2017-02-24 03:17:34 +08:00
|
|
|
const Instruction *Inst)
|
2017-01-26 07:20:25 +08: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-28 04:55:07 +08:00
|
|
|
|
2017-09-16 04:10:09 +08:00
|
|
|
bool OptimizationRemarkMissed::isEnabled() const {
|
|
|
|
const Function &Fn = getFunction();
|
|
|
|
LLVMContext &Ctx = Fn.getContext();
|
|
|
|
return Ctx.getDiagHandlerPtr()->isMissedOptRemarkEnabled(getPassName());
|
2014-05-22 22:19:46 +08:00
|
|
|
}
|
|
|
|
|
2017-02-18 08:42:23 +08:00
|
|
|
OptimizationRemarkAnalysis::OptimizationRemarkAnalysis(
|
|
|
|
const char *PassName, StringRef RemarkName, const DiagnosticLocation &Loc,
|
2017-02-24 03:17:34 +08:00
|
|
|
const Value *CodeRegion)
|
2017-01-26 07:20:25 +08:00
|
|
|
: DiagnosticInfoIROptimization(
|
2016-09-30 00:23:12 +08:00
|
|
|
DK_OptimizationRemarkAnalysis, DS_Remark, PassName, RemarkName,
|
2017-02-18 08:42:23 +08:00
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), Loc, CodeRegion) {}
|
2016-09-30 00:23:12 +08:00
|
|
|
|
2016-09-28 07:47:03 +08:00
|
|
|
OptimizationRemarkAnalysis::OptimizationRemarkAnalysis(const char *PassName,
|
|
|
|
StringRef RemarkName,
|
2017-02-24 03:17:34 +08:00
|
|
|
const Instruction *Inst)
|
2017-01-26 07:20:25 +08:00
|
|
|
: DiagnosticInfoIROptimization(DK_OptimizationRemarkAnalysis, DS_Remark,
|
|
|
|
PassName, RemarkName,
|
|
|
|
*Inst->getParent()->getParent(),
|
|
|
|
Inst->getDebugLoc(), Inst->getParent()) {}
|
2016-09-28 07:47:03 +08:00
|
|
|
|
2017-02-18 08:42:23 +08:00
|
|
|
OptimizationRemarkAnalysis::OptimizationRemarkAnalysis(
|
|
|
|
enum DiagnosticKind Kind, const char *PassName, StringRef RemarkName,
|
2017-02-24 03:17:34 +08:00
|
|
|
const DiagnosticLocation &Loc, const Value *CodeRegion)
|
2017-01-26 07:20:25 +08:00
|
|
|
: DiagnosticInfoIROptimization(Kind, DS_Remark, PassName, RemarkName,
|
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(),
|
2017-02-18 08:42:23 +08:00
|
|
|
Loc, CodeRegion) {}
|
2016-09-30 02:04:47 +08:00
|
|
|
|
2017-09-16 04:10:09 +08:00
|
|
|
bool OptimizationRemarkAnalysis::isEnabled() const {
|
|
|
|
const Function &Fn = getFunction();
|
|
|
|
LLVMContext &Ctx = Fn.getContext();
|
|
|
|
return Ctx.getDiagHandlerPtr()->isAnalysisRemarkEnabled(getPassName()) ||
|
|
|
|
shouldAlwaysPrint();
|
2014-05-22 22:19:46 +08:00
|
|
|
}
|
|
|
|
|
2015-06-16 04:30:22 +08:00
|
|
|
void DiagnosticInfoMIRParser::print(DiagnosticPrinter &DP) const {
|
|
|
|
DP << Diagnostic;
|
|
|
|
}
|
|
|
|
|
2017-02-02 13:41:51 +08:00
|
|
|
DiagnosticInfoOptimizationFailure::DiagnosticInfoOptimizationFailure(
|
2017-02-18 08:42:23 +08:00
|
|
|
const char *PassName, StringRef RemarkName, const DiagnosticLocation &Loc,
|
2017-02-24 03:17:34 +08:00
|
|
|
const Value *CodeRegion)
|
2017-02-02 13:41:51 +08:00
|
|
|
: DiagnosticInfoIROptimization(
|
|
|
|
DK_OptimizationFailure, DS_Warning, PassName, RemarkName,
|
2017-02-18 08:42:23 +08:00
|
|
|
*cast<BasicBlock>(CodeRegion)->getParent(), Loc, CodeRegion) {}
|
2017-02-02 13:41:51 +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;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2017-09-20 07:00:55 +08: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-28 04:55:07 +08:00
|
|
|
Args.emplace_back(S);
|
|
|
|
}
|
|
|
|
|
2017-09-20 07:00:55 +08: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-28 04:55:07 +08:00
|
|
|
Args.push_back(std::move(A));
|
|
|
|
}
|
|
|
|
|
2017-09-20 07:00:55 +08: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-28 04:55:07 +08:00
|
|
|
IsVerbose = true;
|
|
|
|
}
|
|
|
|
|
2017-09-20 07:00:55 +08:00
|
|
|
void DiagnosticInfoOptimizationBase::insert(setExtraArgs EA) {
|
2016-12-02 01:34:44 +08: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-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();
|
|
|
|
}
|
2017-10-04 23:18:11 +08:00
|
|
|
|
2018-12-29 10:02:13 +08:00
|
|
|
void OptimizationRemarkAnalysisFPCommute::anchor() {}
|
|
|
|
void OptimizationRemarkAnalysisAliasing::anchor() {}
|