[PATCH] D36127: [OptDiag] Updating Remarks in SampleProfile
Tarun Rajendran via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Aug 9 16:30:20 PDT 2017
tarunr added a comment.
Thanks for reviewing and for pointing me to examples.
-pass-remarks-with-hotness doesn't seem to be helping me in getting hotness information in these remarks.
================
Comment at: lib/Transforms/IPO/SampleProfile.cpp:505
if (FirstMark) {
- const Function *F = Inst.getParent()->getParent();
- LLVMContext &Ctx = F->getContext();
- emitOptimizationRemark(
- Ctx, DEBUG_TYPE, *F, DLoc,
- Twine("Applied ") + Twine(*R) +
- " samples from profile (offset: " + Twine(LineOffset) +
- ((Discriminator) ? Twine(".") + Twine(Discriminator) : "") + ")");
+ ORE.emit(OptimizationRemark(DEBUG_TYPE, "AppliedSamples", &Inst)
+ << "Applied " << Twine(*R).str()
----------------
anemet wrote:
> Should these be OptimizationRemarkAnalysis instead? These aren't really optimization performed (or missed) i.e. either negative or positive.
Yes, I think that this makes sense
================
Comment at: lib/Transforms/IPO/SampleProfile.cpp:507-508
+ << "Applied " << Twine(*R).str()
+ << " samples from profile (offset: " << Twine(LineOffset).str()
+ << ((Discriminator) ? "." + Twine(Discriminator).str() : "") +
+ ")");
----------------
anemet wrote:
> I don't know much about the internals of sample-based profiling but is LineOffset or Discriminator actionable to the user? I.e. isn't this just a debugging aid if something goes wrong?
The LineOffset and Discriminator may be useful for the user to better determine how the compiler applied the profile to the source. Though, I agree it doesn't seem very actionable to the user
================
Comment at: lib/Transforms/IPO/SampleProfile.cpp:1259-1265
+ ORE.emit(OptimizationRemark(DEBUG_TYPE, "PopularDest", MaxDestInstr)
+ << "most popular destination for conditional branches at "
+ << ((BranchLoc) ? Twine(BranchLoc->getFilename() + ":" +
+ Twine(BranchLoc.getLine()) + ":" +
+ Twine(BranchLoc.getCol()))
+ .str()
+ : Twine("<UNKNOWN LOCATION>").str()));
----------------
anemet wrote:
> You can stream out the instruction like we stream them out I think in LICM as a named-value argument. This may include the LLVM IR name of the instruction which may or may not work in this case, so you may need to tweak DiagnosticInfoOptimizationBase::Argument to do the right thing here.
Currently it looks like the opcode of the instruction gets streamed out in DiagnosticInfoOptimizationBase::Argument. Do you mean that the original source code of the instruction or location of the instruction should be streamed out instead?
Repository:
rL LLVM
https://reviews.llvm.org/D36127
More information about the llvm-commits
mailing list