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

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=21108

            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);
      return;
    }

    // Optimization remarks are selective. They need to check whether the
regexp
    // 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
the
    // diagnostic and return.
    switch (DI.getKind()) {
    case llvm::DK_OptimizationRemark:
      if (!cast<DiagnosticInfoOptimizationRemark>(DI).isEnabled())
        return;
      break;
    case llvm::DK_OptimizationRemarkMissed:
      if (!cast<DiagnosticInfoOptimizationRemarkMissed>(DI).isEnabled())
        return;
      break;
    case llvm::DK_OptimizationRemarkAnalysis:
      if (!cast<DiagnosticInfoOptimizationRemarkAnalysis>(DI).isEnabled())
        return;
      break;
    default:
      break;
    }

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>