[PATCH] D122539: [SelectionDAG][DAGCombiner] Reuse exist node by reassociate

[chenglin.bi via Phabricator via llvm-commits]

bcl5980 added a comment.

In D122539#3603739 <https://reviews.llvm.org/D122539#3603739>, @kripken wrote:

> This somehow caused a regression in the wasm targets, which I bisected to here. Certain files when compiled with `-O1` appear to hang for a very long time (maybe forever). This happened on the Bullet physics engine codebase in the Emscripten test suite, but affects all wasm targets (wasm32-unknown-unknown, -wasi, and -emscripten).
>
> This doesn't affect other targets, which I guess is why it wasn't noticed before it reached our CI. So maybe this uncovered an existing wasm bug.
>
> @tlively is reducing this atm. Posting the original testcase here for future reference.F23552133: bug.cpp <https://reviews.llvm.org/F23552133>
> STR: `clang++ -target wasm32-unknown-unknown  -O1 -c bug.cpp`. That should take less than a second normally, but from this change landing it hangs a very long time (I measured at least 10 seconds during bisection).

Thanks for the case. I try to minimize the test:

  target triple = "wasm32-unknown-unknown"
  
  define float @reassociate_xor(float %x, float %y) {
  entry:                                           ; preds = %if.then, %entry
    %cmp0 = fcmp ule float %x, 0x3E80000000000000
    %cmp1 = fcmp ugt float %y, 0x3E80000000000000
    %cmp2 = xor i1 %cmp0, %cmp1
    br i1 %cmp2, label %if.end.i, label %if.then.i
  
  if.then.i:                                        ; preds = %if.end
    br label %if.end.i
  
  if.end.i:                                         ; preds = %if.then.i, %if.end
    %s = phi i32 [ 1, %entry ], [ 0, %if.then.i ]
    ret float %x
  }

It looks `rebuildSetCC` will visitXor in a loop keep the original dag before reassoicate cause deadloop. 
I will continue work on it to find a solution.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122539/new/

https://reviews.llvm.org/D122539