[all-commits] [llvm/llvm-project] fed4e7: [test][MemDep] Correct the 'NOT' checks in the inv...

[Björn Pettersson via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: fed4e7d0d2a45b1e49998054379af94d1ba43edd
      https://github.com/llvm/llvm-project/commit/fed4e7d0d2a45b1e49998054379af94d1ba43edd
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2023-03-17 (Fri, 17 Mar 2023)

  Changed paths:
    M llvm/test/Analysis/MemoryDependenceAnalysis/invalidation.ll

  Log Message:
  -----------
  [test][MemDep] Correct the 'NOT' checks in the invalidation.ll test case. NFC

The MemoryDependenceAnalysis/invalidation.ll test case was using
  ; CHECK-NOT-AA-INVALIDATE:
but I think the intention was to use
  ; CHECK-AA-INVALIDATE-NOT:

Simply changing the checks like that would make the test fail.

The old statement that AA being stateless would result in nothing
to invalidate when doing invalidate<aa> is not true afaict.
It would be different if for example doing invalidate<basic-aa>, then
the AAManager isn't invalidated (and then neither memdep would be
invalidated). But when the AAManager itself is invalidated then we
should expect to find both "Invalidating analysis: AAManager" and
"Invalidating analysis: MemoryDependenceAnalysis" in the output.

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


  Commit: 81d6310da1fc54f0ca0de6fa13246d6071edb0cf
      https://github.com/llvm/llvm-project/commit/81d6310da1fc54f0ca0de6fa13246d6071edb0cf
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2023-03-17 (Fri, 17 Mar 2023)

  Changed paths:
    M llvm/include/llvm/Analysis/LoopAccessAnalysis.h
    M llvm/lib/Analysis/LoopAccessAnalysis.cpp
    A llvm/test/Analysis/LoopAccessAnalysis/invalidation.ll

  Log Message:
  -----------
  [LAA] Fix transitive analysis invalidation bug by implementing LoopAccessInfoManager::invalidate

The default invalidate method for analysis results is just looking
at the preserved state of the pass itself. It does not consider if
the analysis has an internal state that depend on other analyses.
Thus, we need to implement LoopAccessInfoManager::invalidate in order
to catch if LoopAccessAnalysis needs to be invalidated due to
transitive analyses such as AAManager is being invalidated. Otherwise
we might end up having references to an AAManager that is stale.

Fixes https://github.com/llvm/llvm-project/issues/61324

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


  Commit: 951a980dc7aa61b1d414e7d565166ee8071367c6
      https://github.com/llvm/llvm-project/commit/951a980dc7aa61b1d414e7d565166ee8071367c6
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2023-03-17 (Fri, 17 Mar 2023)

  Changed paths:
    M llvm/lib/Analysis/BlockFrequencyInfo.cpp
    M llvm/lib/Analysis/BranchProbabilityInfo.cpp
    M llvm/lib/Analysis/LoopAccessAnalysis.cpp
    M llvm/lib/Analysis/ScalarEvolution.cpp

  Log Message:
  -----------
  [Analysis] Make order of analysis executions more stable

When debugging and using debug-pass-manager (e.g. in regression tests)
we prefer a consistent order in which analysis passes are executed.
But when for example doing

  return MyClass(AM.getResult<LoopAnalysis>(F),
                 AM.getResult<DominatorTreeAnalysis>(F));

then the order in which LoopAnalysis and DominatorTreeAnalysis isn't
guaranteed, and might for example depend on which compiler that is
used when building LLVM.

I've not scanned the full source tree, but this fixes some occurances
of the above pattern found in lib/Analysis.

This problem was discussed briefly in review for D146206.


Compare: https://github.com/llvm/llvm-project/compare/5d276380b0b4...951a980dc7aa