This is an archive of the discontinued LLVM Phabricator instance.

Perform DIV,REM -> DIVREM combining for all affected nodes at once.
ClosedPublic

Authored by tyomitch on Oct 14 2015, 10:34 AM.

Details

Summary

If the nodes are converted to DIVREM one at a time, then the resulting DIVREM
may get legalized by the backend into something target-specific that we won't
be able to recognize and correlate with the remaining nodes.

This recovers most of the tests broken by the previous patch.

Diff Detail

Repository
rL LLVM

Event Timeline

tyomitch updated this revision to Diff 37365.Oct 14 2015, 10:34 AM
tyomitch retitled this revision from to Perform DIV,REM -> DIVREM combining for all affected nodes at once..
tyomitch updated this object.
tyomitch added reviewers: RKSimon, eli.friedman.
tyomitch added a subscriber: llvm-commits.

Hi Artyom,

I was under the impression that these two patches were complete. But if I read right on your description, "This recovers most of the tests broken by the previous patch." means that not all the tests are fixed. Is that correct?

I have done changes in that area before, and I have always met with numerous bugs in tests due to the complicated nature of div/rem on different targets.

I like where your patches are going, but I worry if they're really correct to the other targets.

I'd recommend you to abandon D13732, merge those changes here and make sure that *all* tests pass with flying colours.

cheers,
--renato

tyomitch updated this revision to Diff 37734.Oct 19 2015, 4:25 AM
tyomitch added a subscriber: john.brawn.

The two patches merged, and all tests confirmed as passing.

Right, I think I got the idea of the code...

This will combine any div+rem or rem+div, but also account for div+divrem and rem+divrem. Only not for divrem+divrem, if both were converted to divrem due to ABI rules, ex: a div+rem that were individually converted earlier, and now are being merged. I imagine this doesn't occur in practice.

Now, what I don't understand is the motivation. I get it that you found some patterns that weren't being recognised, but there are no tests to show what it is. It'd be good to add a new test with all the cases that couldn't be merged before.

cheers,
--renato

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
2232 ↗(On Diff #37734)

Why not getValue(0), here?

Now, what I don't understand is the motivation.

The motivation is to enable D13862 -- I've now set you as a reviewer there, too.

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
2232 ↗(On Diff #37734)

That's how it was in the original code in LegalizeDAG.cpp

I don't have a particular preference, and I don't mind changing it to getValue(0)

The motivation is to enable D13862 -- I've now set you as a reviewer there, too.

Right, so the patterns that ended up as target-specific (and thus not lowered optimally) were due to that change first?

If that's the case, than this is a fix for the problems raised by that commit, and thus doesn't need any additional tests if, and only if, that patch breaks some tests.

If it does, please commit both at the same time. If not, please provide examples where those patterns got wrong by that patch, and fix them with this patch.

Thanks!

The motivation is to enable D13862 -- I've now set you as a reviewer there, too.

Right, so the patterns that ended up as target-specific (and thus not lowered optimally) were due to that change first?

Not quite: in order to be able to apply D13862, we need to take the DIV,REM -> DIVREM combining out of the lowering stage.
Otherwise, when we set DIV and REM to be legalized to libcalls, instead of the DIVREM, we lose the ability to combine them together.

Therefore, my plan was to apply D13862 after D13733.
In other words, D13733 doesn't fix any problems arising from D13862 -- it prevents their occurrence :)

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
2232 ↗(On Diff #37734)

Any preference here?

rengolin accepted this revision.Oct 20 2015, 5:22 AM
rengolin added a reviewer: rengolin.

LGTM, thanks!

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
2232 ↗(On Diff #37734)

Not really. I'll leave it to you to decide. :)

This revision is now accepted and ready to land.Oct 20 2015, 5:22 AM
This revision was automatically updated to reflect the committed changes.