This is an archive of the discontinued LLVM Phabricator instance.

Integer division expansion should handle constant divisors intelligently
Needs ReviewPublic

Authored by dshtilman on Nov 29 2016, 7:07 PM.

Details

Reviewers
milseman
Summary

The following patch improves integer division sw expansion.
Namely - the case of division by a constant, which would be expanded to a simple multiplication by a magic number rather than a full division loop.
Implementation follows the DAG code in TargetLowering::BuildSDIV().
Ref: "Hacker's Delight" or "The PowerPC Compiler Writer's Guide”.

Please review.
Dmitri

Diff Detail

Repository
rL LLVM

Event Timeline

dshtilman updated this revision to Diff 79694.Nov 29 2016, 7:07 PM
dshtilman retitled this revision from to Integer division expansion should handle constant divisors intelligently.
dshtilman updated this object.
dshtilman added a reviewer: vsk.
dshtilman set the repository for this revision to rL LLVM.
dshtilman added subscribers: llvm-commits, qcolombet, RKSimon.
joerg added a subscriber: joerg.Nov 30 2016, 3:19 AM

Why is this code necessary? LLVM already implements the division-by-constant optimisation.

vsk edited reviewers, added: milseman; removed: vsk.Nov 30 2016, 8:51 AM
vsk added a subscriber: vsk.

Why is this code necessary? LLVM already implements the division-by-constant optimisation.

Some platforms don't use SelectionDAG isel so they would not catch that optimization.
This is an optimization for those who use this div sw expansion utility.

joerg added a comment.Dec 1 2016, 1:45 PM

That sounds like a really really bad justification for duplicating a non-trivial algorithm.

joerg changed the visibility from "All Users" to "Public (No Login Required)".Dec 1 2016, 2:19 PM

Hi Joerg,

There is duplication already between InstCombine and DAGCombine, why is this one different?

For FastISel users, how would you approach that?

Thanks,
-Quentin

joerg added a comment.Dec 8 2016, 11:38 AM

Refactor the core of the computation into a function that can be used by both. A class with emitters for the different main cases might be the best, especially if someone wants to add further special case handling at some point.