[llvm-dev] Assertion `LICM.getLoopToAliasSetMap().empty() && "Didn't free loop alias sets"' failed.

[cszide via llvm-dev]

Hi everyone,
Recently, I made some tests for LLVM/Clang/opt, and I found many test cases that can cause a crash bug for opt with "...-loop-unroll -licm...".
For the truck version of LLVM, the output is "llvm/lib/Transforms/Scalar/LICM.cpp:222: virtual bool {anonymous}::LegacyLICMPass::doFinalization(): Assertion `LICM.getLoopToAliasSetMap().empty() && "Didn't free loop alias sets"' failed."
For example, when compiling the following source code with the pass sequence "-loop-rotate -gvn -prune-eh -loop-unroll -licm", the bug can be triggered.
---------------------------------------------------
#include "csmith.h"
g, h;
int16_t a();
b() {
  a();
  for (;;) {
    uint64_t c;
    int d, e, f;
    for (d = 0; d < 4; d++)
      for (; e < f;)
        c;
  }
}
int16_t a() {
  for (; 0;)
    for (; 0;)
      for (; 0;)
        ;
  g = 0;
  for (; g < 5; g++)
    for (; h;)
      ;
}
$clang -O3 -c -emit-llvm  -mllvm -disable-llvm-optzns small1.c -o small1.bc
$opt -loop-rotate -gvn -prune-eh -loop-unroll -licm small1.bc -o small1-opt.bc
----------------------------------------------------
My question is that why the information in LoopToAliasSetMap must be freed before the doFinalization() function.
When the program runs into the doFinalization() function, the information in LoopToAliasSetMap is no longer useful,
so can we free these elements in LoopToAliasSetMap manually? Like this:
bool doFinalization() override {
    //assert(LICM.getLoopToAliasSetMap().empty() &&
           //"Didn't free loop alias sets");
    for (auto &LTAS : LICM.getLoopToAliasSetMap())
        delete LTAS.second;
    LICM.getLoopToAliasSetMap().clear();
    return false;
  }
I test it on my system and it works, but I do not know whether there are some side-effects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190126/e3029d5f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: small1.bc
Type: application/octet-stream
Size: 2764 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190126/e3029d5f/attachment.obj>