[all-commits] [llvm/llvm-project] bee8dc: [SCEV] Fix and validate ValueExprMap/ExprValueMap ...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bee8dcda1f01831808885ea23f9ac1467ce660f5
      https://github.com/llvm/llvm-project/commit/bee8dcda1f01831808885ea23f9ac1467ce660f5
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2021-11-26 (Fri, 26 Nov 2021)

  Changed paths:
    M llvm/include/llvm/Analysis/ScalarEvolution.h
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/test/CodeGen/PowerPC/more-dq-form-prepare.ll
    A llvm/test/Transforms/LoopStrengthReduce/X86/nested-ptr-addrec.ll

  Log Message:
  -----------
  [SCEV] Fix and validate ValueExprMap/ExprValueMap consistency

Relative to the previous landing attempt, this makes
insertValueToMap() resilient against the value already being
present in the map -- previously I only checked this for the
createSimpleAffineAddRec() case, but the same issue can also
occur for the general createNodeForPHI(). In both cases, the
addrec may be constructed and added to the map in a recursive
query trying to create said addrec. In this case, this happens
due to the invalidation when the BE count is computed, which
ends up clearing out the symbolic name as well.

-----

This adds validation for consistency of ValueExprMap and
ExprValueMap, and fixes identified issues:

* Addrec construction directly wrote to ValueExprMap in a few places,
  without updating ExprValueMap. Add a helper to ensures they stay
  consistent. The adjustment in forgetSymbolicName() explicitly
  drops the old value from the map, so that we don't rely on it
  being overwritten.
* forgetMemoizedResultsImpl() was dropping the SCEV from
  ExprValueMap, but not dropping the corresponding entries from
  ValueExprMap.

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