Souper crash in codegen from valid transformation

[manasij7479]

Given the following transformation (derived from spec17) in the redis cache:

%0:i32 = var
%1 = block 2
%2 = block 1
%3:i64 = var (range=[-2147483648,6442450943))
%4:i64 = addnsw 1:i64, %3
%5:i64 = phi %2, %4
%6:i32 = trunc %5
%7:i32 = phi %1, %0, %6
%8:i1 = sle %0, %7
pc %8 0:i1
%9:i32 = addnsw 1:i32, %7
infer %9
%10 = block 1
%11:i64 = phi %10, %4
%12:i32 = trunc %11
%13:i32 = add 1:i32, %12
result %13

And the following reduced source file:

class b {
  b *m_fn1();
  int c;
  int f;
  short *d;
};
b *b::m_fn1() {
  if (f) {
    int e, a = d[c++];
    if (a >= 9) {
      while (c < f && (a = d[c++]) >= 0 && a <= 9)
        e = e - 8;
      if (e)
        ;
    } else
      throw;
    if (a == 2)
      if (c >= f)
        ;
      else
        d[c++];
  }
}

Souper crashes with fatal error: error in backend: Unhandled Souper instruction phi in Codegen::getValue()
Invocation:
souper/third_party/llvm-Release-install/bin/clang++ -c -O2 -Xclang -load -Xclang souper/build/libsouperPass.so -mllvm -souper-external-cache -mllvm -disable-all-peepholes foo.cpp

To reproduce from scratch:

• Ensure Redis is running
• Build the reduced source file with sclang and the following environment variables set

$ env | grep SOUPER
SOUPER_ENUMERATIVE_SYNTHESIS_MAX_INSTS=1
SOUPER_DOUBLE_CHECK=1
SOUPER_DISABLE_LLVM_PEEPHOLES=1

[regehr]

we're never supposed to synthesize a phi, but that transformation seems to contain a new phi -- so the crash is correct but the optimization looks weird. can you isolate the code that leads to this transformation so we can understand what's going on here?

[regehr]

%11 looks like it was supposed to be %4, so we need to understand how that happened. if %11 was %4 then we'd not have a new phi and we'd not get the crash. that looks like the bug to me.

[manasij7479]

The 'block' should be same too.
Somewhere we are not reusing the block from LHS during synthesis.

This is how to synthesize this with souper-check without involving sclang
./souper-check -reinfer-rhs -souper-enumerative-synthesis-max-instructions=1 -souper-dataflow-pruning -souper-double-check /tmp/phi.opt
Where phi.opt contains the transformation in the issue.
I'll investigate what''s causing this to be synthesized.

[regehr]

run under valgrind and such -- there could be an uninitialized bug that is causing things to get garbled.

yes, the key question is why that block wasn't getting reused -- if that happened, it wouldn't look like we synthesized a phi on the RHS, which of course we did not.

[regehr]

@manasij7479 reminder to fix this