This is an archive of the discontinued LLVM Phabricator instance.

[TLI][X86][AArch64] Generalize isDesirableToCommuteWithShift() hook and enable for X86
AbandonedPublic

Authored by lebedev.ri on Sep 20 2018, 3:03 AM.

Details

Diff Detail

Repository
rL LLVM

Event Timeline

lebedev.ri created this revision.Sep 20 2018, 3:03 AM
lebedev.ri added inline comments.Sep 20 2018, 5:22 AM
lib/Target/X86/X86ISelDAGToDAG.cpp
2630–2633 ↗(On Diff #166251)

Actually, this does not have any test coverage it seems.
So i'm not sure what extra tests this needs.

lebedev.ri retitled this revision from [X86][BMI] BEXTR: handle (X >> C1) & (C2 << C3) as ((X >> (C1 + C3)) & C2) << C3 (PR38938) to [DagCombine][X86][AArch64] Try to unfold (X >> C1) & (C2 << C3) as ((X >> (C1 + C3)) & C2) << C3 (PR38938).
lebedev.ri edited the summary of this revision. (Show Details)

Comment # 4 on bug 38938 from Craig Topper

We need to get the shl created before the address mode for the inc is
selected
in Simon's test case. So we need to handle this in DAG combine or in
preprocessiseldag.

Ok, makes sense.
This turned out to be rather problematic :S

This is *very* prone to endless loops (we unfold the pattern,
and then SimplifyDemandedBits folds it back).
I suspect the change in DAGCombiner::SimplifyDemandedBits()
is too ugly, but i don't have any better ideas.
Anything else appears to deadlock.

These aren't all the test changes, but most of them.

lebedev.ri retitled this revision from [DagCombine][X86][AArch64] Try to unfold (X >> C1) & (C2 << C3) as ((X >> (C1 + C3)) & C2) << C3 (PR38938) to [TLI][X86][AArch64] Generalize isDesirableToCommuteWithShift() hook and enable for X86.

Ok, so the fix for the *given* problem is so much simpler.

AArch64 already overrode isDesirableToCommuteWithShift() with this very pattern.
But we clearly want to do the same for x86.
So just generalize it.

FIXME: i'm not sure if isBitFieldExtractPattern() should be a virtual function?

Rebased ontop of more tests, NFC.
Will look into x86 dagcombine next..

@lebedev.ri Are you able to refactor this now that D52570 has landed?

Rebased now that D52570 has landed.

Can you remove the D52293 dependency and just move the current code to DAG so we can fix PR38938?

We don't want this hook for X86?

Does not appear to be worthwhile; effectively superseeded by D53126.

Abandon this?

lebedev.ri abandoned this revision.Oct 11 2018, 2:07 PM

Does not appear to be worthwhile; effectively superseeded by D53126.

Abandon this?

Oops, meant to and forgot :)