This is an archive of the discontinued LLVM Phabricator instance.

[SelectionDAG][DAGCombiner] Reuse exist node by reassociate
ClosedPublic

Authored by bcl5980 on Mar 26 2022, 9:37 PM.

Details

Diff Detail

Event Timeline

bcl5980 created this revision.Mar 26 2022, 9:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 26 2022, 9:37 PM
bcl5980 requested review of this revision.Mar 26 2022, 9:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 26 2022, 9:37 PM
pengfei added inline comments.Mar 27 2022, 1:52 AM
llvm/test/CodeGen/X86/masked-iv-safe.ll
269 ↗(On Diff #418434)

This seems regression. The same below.

bcl5980 added inline comments.Mar 27 2022, 2:16 AM
llvm/test/CodeGen/X86/masked-iv-safe.ll
269 ↗(On Diff #418434)

Yeah, this change brings some regressions because of two reasons:

  1. The case you comment, instruction sequence change causes extra compare instructions
  2. [load/store (add (add x, y), constant)]. Many targets support ld/st with imm offset. If we reassociate instructions, it will miss the address mode pattern match.

But I think they should be fixed on every backend's isReassocProfitable. I prefer to fix these on individual changes.

pengfei added inline comments.Mar 27 2022, 3:20 AM
llvm/test/CodeGen/X86/masked-iv-safe.ll
269 ↗(On Diff #418434)

We shouldn't commit a patch with any known regressions. An individual fix is fine, but it should be ahead of this one so that we won't bring the regression at any time.

bcl5980 planned changes to this revision.Mar 28 2022, 1:47 AM

Waiting for other changes check in

bcl5980 updated this revision to Diff 436276.Jun 12 2022, 10:33 PM
bcl5980 updated this revision to Diff 436323.Jun 13 2022, 3:01 AM

fix all regressions

bcl5980 updated this revision to Diff 436673.Jun 13 2022, 11:57 PM

remove condition legalDag

A few style comments

llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
1022–1024
if (auto *C1 = dyn_cast<ConstantSDNode>(N0.getOperand(1))) {
1101
if (auto *GA = dyn_cast<GlobalAddressSDNode>(N0.getOperand(1)))
1108

(style) Early-out:

auto *LoadStore = dyn_cast<MemSDNode>(Node);
if (!LoadStore)
  return false;
bcl5980 updated this revision to Diff 436699.Jun 14 2022, 1:43 AM

fix coding style issue

bcl5980 marked 3 inline comments as done.Jun 14 2022, 1:44 AM
RKSimon added inline comments.Jun 19 2022, 2:42 AM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
1062

auto *LoadStore

bcl5980 updated this revision to Diff 438247.Jun 19 2022, 9:43 PM

update coding style

bcl5980 marked an inline comment as done.Jun 19 2022, 9:43 PM
RKSimon accepted this revision.Jun 20 2022, 1:27 AM

LGTM - with one more style minor

llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
1037
if (auto *LoadStore = dyn_cast<MemSDNode>(Node);)
This revision is now accepted and ready to land.Jun 20 2022, 1:27 AM
This revision was landed with ongoing or failed builds.Jun 20 2022, 6:45 PM
This revision was automatically updated to reflect the committed changes.
dyung added a subscriber: dyung.Jun 22 2022, 7:24 PM

Hi @bcl5980, one of our internal tests started to hit an assertion failure while building which I bisected back to this change. I have filed the details as issue #56170, can you take a look?

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.


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).

Reverted by rG9c2bf534f59.
Will try to fix issues later.

Allen added a subscriber: Allen.Jun 22 2022, 10:57 PM

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.


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.

Use getMinSignedBits instead of getBitwidth - fixes for Issue #56170

llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
1028

Are these redundant? CombinedValueIntVal handles this better below

1031

getBitWidth() -> getMinSignedBits()

1059
if (C2APIntVal.getMinSignedBits() > 64)
  return false;
bcl5980 reopened this revision.Jun 23 2022, 7:23 AM
This revision is now accepted and ready to land.Jun 23 2022, 7:23 AM
bcl5980 planned changes to this revision.Jun 23 2022, 3:52 PM
bcl5980 updated this revision to Diff 439614.Jun 23 2022, 9:26 PM

fix 56170

This revision is now accepted and ready to land.Jun 23 2022, 9:26 PM
bcl5980 planned changes to this revision.Jun 23 2022, 9:27 PM
bcl5980 updated this revision to Diff 439631.Jun 23 2022, 11:16 PM

fix dead loop in rebuildSetCC

This revision is now accepted and ready to land.Jun 23 2022, 11:16 PM
bcl5980 requested review of this revision.Jun 23 2022, 11:16 PM
RKSimon added inline comments.Jun 24 2022, 12:08 AM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
1039

We have a C2APIntVal use here that I don't think has a getSignificantBits check?

llvm/test/Transforms/Reassociate/pr56170.ll
4 ↗(On Diff #439631)

Shouldn't this be in tests/Codegen/X86?

bcl5980 added inline comments.Jun 24 2022, 12:27 AM
llvm/test/Transforms/Reassociate/pr56170.ll
4 ↗(On Diff #439631)

Actually almost every target can trigger this issue. Move the test to x86 is OK for me.

bcl5980 updated this revision to Diff 439654.Jun 24 2022, 12:31 AM

add c2 sign bits check
move pr56170.ll to Codegen/X86

RKSimon accepted this revision.Jun 24 2022, 2:15 AM

LGTM cheers

This revision is now accepted and ready to land.Jun 24 2022, 2:15 AM
This revision was landed with ongoing or failed builds.Jun 24 2022, 8:15 AM
This revision was automatically updated to reflect the committed changes.