[PATCH] D110673: [clang] Don't modify OptRemark if the argument is not relevant

James Nagurne via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Sep 29 13:03:35 PDT 2021


JamesNagurne added a comment.

The trigger for the remark I'm seeing is llvm::shouldInline in InlineAdvisor.cpp ((https://github.com/llvm/llvm-project/blob/2240deb9766cc080b351016b0d7f975d7249b113/llvm/lib/Transforms/IPO/Inliner.cpp#L425) which is called in a top-level AlwaysInlinerLegacyPass

Clang Release build with LLVM_ENABLE_ASSERTIONS=ON

  %clang_cc1 %s -Rpass=inline -Rno-pass -emit-llvm -o -



- ORE.emit is called, which checks 'enabled()' first
- enabled checks if any of CodeGenOpts.OptimizationRemarkAnalysis, OptimizationRemarkMissed, or OptimizationRemark have a valid pattern (https://github.com/llvm/llvm-project/blob/2240deb9766cc080b351016b0d7f975d7249b113/clang/lib/CodeGen/CodeGenAction.cpp#L73)
  - Analysis and Missed have valid patterns, while OptimizationRemark does not
  - This coincides with ParseOptimizationRemark returning a result with a valid pattern for only "pass-analysis" and "pass-missed"
- The resulting diagnostic is handled by clang::BackendConsumer::OptimizationRemarkHandler (https://github.com/llvm/llvm-project/blob/2240deb9766cc080b351016b0d7f975d7249b113/clang/lib/CodeGen/CodeGenAction.cpp#L708)
  - The regex is '.*', so the pattern check passes, and then call EmitOptimizationMessage
  - Diags (the DiagnosticEngine modified by clang::ProcessWarningOptions) is used to report the diagnostic, given a DebugLoc and an ID
  - Diags->getDiagnosticLevel(DiagID, Loc) is Remark, so the diagnostic is emitted

-----

Nothing here seems out of place. Regarding ProcessWarningOptions:
I've noticed that our tools being validated are doing a -cc1 round trip due to having LLVM_ENABLE_ASSERTIONS set on ON (https://github.com/llvm/llvm-project/blob/7dffb8b4da530d481977e31f439a92c5f6f2174a/clang/lib/Frontend/CompilerInvocation.cpp#L642)

- -cc1 options are parsed and generate a temporary CompilerInvocation
- The temporary CompilerInvocation is used to generate a second list of arguments
- The second list of arguments are parsed into the real CompilerInvocation
- A third list of arguments are generated from the real CompilerInvocation and compared against the second set to ensure that they are identical

If I run clang -cc1 with -no-round-trip-args, I no longer see the remarks. Adding some prints for each argument list in the round trip, I get (ignoring options unrelated to diagnostics):

- Initial (CommandLineArgs): [-Rpass=inline, -Rno-pass]
- GeneratedArgs1: [-Rno-pass, -Rpass-missed=.*, -Rpass-analysis=.*, -fdiagnostics-hotness-threshold=0]
- GeneratedArgs2: [-Rno-pass, -Rpass-missed=.*, -Rpass-analysis=.*, -fdiagnostics-hotness-threshold=0]

So, the round-trip check passes, but it looks like some internal consistency has been violated because parsing the initial CommandLineArgs into a CompilerInvocation does not result in erroneous remarks, but re-generating and parsing the arguments again leads to a change in behavior.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110673/new/

https://reviews.llvm.org/D110673



More information about the cfe-commits mailing list