[all-commits] [llvm/llvm-project] 51d4c7: [GlobalOpt] Fix debug variance problem in hasOnlyC...

[mikaelholmen via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 51d4c7ceea61b5d83ba52398b5ca6d58d7551044
      https://github.com/llvm/llvm-project/commit/51d4c7ceea61b5d83ba52398b5ca6d58d7551044
  Author: Mikael Holmen <mikael.holmen at ericsson.com>
  Date:   2022-09-02 (Fri, 02 Sep 2022)

  Changed paths:
    M llvm/lib/Transforms/IPO/GlobalOpt.cpp
    M llvm/test/Transforms/GlobalOpt/PowerPC/coldcc_coldsites.ll
    A llvm/test/Transforms/GlobalOpt/dbg-intrinsic-loopanalysis.ll

  Log Message:
  -----------
  [GlobalOpt] Fix debug variance problem in hasOnlyColdCalls

hasOnlyColdCalls skipped over calls to intrinsics, but it did so after
checking the linkage of the called function. This meant that the presence
of a call to a debug intrinsic could affect the outcome of the
optimization.

In my original reproducer (for an out of tree target) it was particularly
interesting, because the actual IR after GlobalOpt was not different with
debug instrinsics present, so -print-after-all printouts didn't show
anything there.

However, without debuginfo, GlobalOpt went further and ran
BlockFrequencyAnalysis and (more importanly) LoopAnalysis, and later on in
the pipeline, instcombine behaved in different ways when LoopInfo was
present.

So a call to a dbg.declare prevented running LoopAnalysis in
GlobalOpt, which later prevented InstCombine from doing an optimization.

The dbg-intrinsic-loopanalysis.ll testcase tries to expose this.

Then I also noted that adding a dbg.declare actually made the existing
testcase colccc_coldsites.ll generate different code, so I modified that
to now test it behaves the same way with and without the dbg.declare.

Reviewed By: nikic, fhahn

Differential Revision: https://reviews.llvm.org/D133193