[llvm-bugs] [Bug 51754] New: SimpleLoopUnswitch not informing pass manager when child loops are deleted during nontrivial unswitch

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51754

            Bug ID: 51754
           Summary: SimpleLoopUnswitch not informing pass manager when
                    child loops are deleted during nontrivial unswitch
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: bjorn.a.pettersson at ericsson.com
                CC: llvm-bugs at lists.llvm.org

Problems were observed downstream when running tests using "opt
-enable-new-pm=1 -O3 -S -extra-vectorizer-passes=1 -enable-loop-distribute".
For a specific input the compiler sometimes just crashed, sometimes we hit an
assertion, etc. Although this was very non-deterministic and it only failed
occasionally.

A somewhat reduced test case included 2 functions "foo" and "bar". And some
debugging indicated the following scenario:

1) When running loop-distribute on "foo" LoopAccessAnalysis was calculated for
some loops in that functions. Those analyses were cached in the
LoopAnalysisManager associated with a LoopAnalysisManagerFunctionProxy based on
a Loop*.

2) Later when running SimpleLoopUnswitch a loop "a" was transformed, and as
part of that a child loop "b" was removed/replaced. The Loop object for "b" was
destroyed (still being allocated by the BumpPtrAllocator, and without removing
the analyses cached on the corresponding Loop*).

3) Here something triggeres a reset of the BumpPtrAllocator used for allocating
Loop objects (maybe throwing away loop analyses at the end of the loop pass
manager).

4) When running loop-distribution later, for "bar", first a Loop object was
created for a loop "c". And then LoopAccessAnalysis were requested. Depending
on if the Loop object for "c" happened to use the same address as the stale
analysis for loop "b" we sometimes ended up fetching the LoopAccessAnalysis
result for "b" instead of recalculating the analysis for "c".

-- 
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/20210905/e8e0c9b8/attachment-0001.html>