This is an archive of the discontinued LLVM Phabricator instance.

[DAG] DAGCombiner::useDivRem - recognise sub(X,mul(div(X,Y),Y)) as a rem(X,Y)
AbandonedPublic

Authored by RKSimon on Jul 24 2021, 6:18 AM.

Details

Summary

Attempt to match a sub(X,mul(div(X,Y),Y)) pattern as srem/urem as a last chance to merge into a divrem instruction.

For reference, the DivRemPairs pass explicitly won't merge cases when the sub/mul and div are in the same block:

// If the target supports div+rem and the instructions are in the same block
// already, there's nothing to do. The backend should handle this. If the
// target does not support div+rem, then we will decompose the rem.
if (HasDivRemOp && RemInst->getParent() == DivInst->getParent())
  continue;

Diff Detail

Event Timeline

RKSimon created this revision.Jul 24 2021, 6:18 AM
RKSimon requested review of this revision.Jul 24 2021, 6:18 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 24 2021, 6:18 AM
lebedev.ri added inline comments.Jul 24 2021, 6:38 AM
llvm/test/CodeGen/X86/div-rem-pair-recomposition-signed.ll
977

Could use a test with mismatching y's too, and both of them.

RKSimon updated this revision to Diff 361455.Jul 24 2021, 7:24 AM

rebase with additional negative tests

I think this is mainly a bug in X86TTIImpl::hasDivRemOp().
Why do we decide here in backend that we are allowed to produce divrem, but the pass is told that is is not allowed to?

RKSimon edited the summary of this revision. (Show Details)Jul 24 2021, 8:22 AM
RKSimon abandoned this revision.Jul 24 2021, 10:10 AM

I'm so sorry, this was chasing what I thought was a bug in PR51014 but was just a screwup on my part - sorry for wasting your time

I'm so sorry, this was chasing what I thought was a bug in PR51014 but was just a screwup on my part - sorry for wasting your time

I do not follow.
It *is* an expanded rem: https://alive2.llvm.org/ce/z/oYT73P
And the divrempairs pass actively fights against it: https://godbolt.org/z/9P7qeqb9E
Because TargetTransformInfo::hasDivRemOp() said that there is no divrem for i8.

I'm so sorry, this was chasing what I thought was a bug in PR51014 but was just a screwup on my part - sorry for wasting your time

I do not follow.
It *is* an expanded rem: https://alive2.llvm.org/ce/z/oYT73P
And the divrempairs pass actively fights against it: https://godbolt.org/z/9P7qeqb9E
Because TargetTransformInfo::hasDivRemOp() said that there is no divrem for i8.

Ah yes, -mtriple=x86_64--- helps https://godbolt.org/z/o68Wea4r1.
I didn't pay enough attention :/