[LLVMbugs] [Bug 21108] New: Optimization remarks are "always on" in LTO

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Sep 30 20:50:29 PDT 2014


            Bug ID: 21108
           Summary: Optimization remarks are "always on" in LTO
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: dexonsmith at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

r206400 and r209442 added support to diagnostic handlers to check for
optimization remarks.  However, this support wasn't pulled through to
`LTOCodeGenerator:: DiagnosticHandler2()`, so anyone using libLTO gets this
remarks by default.

The logic in `LLVMContext::diagnose()` looks like this:

    // If there is a report handler, use it.
    if (pImpl->DiagnosticHandler) {
      pImpl->DiagnosticHandler(DI, pImpl->DiagnosticContext);

    // Optimization remarks are selective. They need to check whether the
    // pattern, passed via one of the -pass-remarks* flags, matches the name of
    // the pass that is emitting the diagnostic. If there is no match, ignore
    // diagnostic and return.
    switch (DI.getKind()) {
    case llvm::DK_OptimizationRemark:
      if (!cast<DiagnosticInfoOptimizationRemark>(DI).isEnabled())
    case llvm::DK_OptimizationRemarkMissed:
      if (!cast<DiagnosticInfoOptimizationRemarkMissed>(DI).isEnabled())
    case llvm::DK_OptimizationRemarkAnalysis:
      if (!cast<DiagnosticInfoOptimizationRemarkAnalysis>(DI).isEnabled())

The wrong fix is to move the `switch` before the call out to the handler.  This
would fix LTO, but break clang.

Two other fixes come to mind:

 1. Duplicate the switch statement in `LTOCodeGenerator::DiagnosticHandler2()`.
 I don't like this.

 2. Change `LLVMContext::DiagnosticHandlerTy` to take an extra `bool`
parameter, which indicates whether the backend suggests this should be
"ignored" (would the `switch` return early?).  `clang` can use its own logic;
`LTOCodeGenerator` can use the parameter.

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141001/cec8469e/attachment.html>

More information about the llvm-bugs mailing list