[PATCH] D122539: [SelectionDAG][DAGCombiner] Reuse exist node by reassociate
chenglin.bi via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 23 04:03:01 PDT 2022
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
More information about the llvm-commits
mailing list