This is an archive of the discontinued LLVM Phabricator instance.

[SCEV] Opportunistically interpret unsigned constraints as signed
ClosedPublic

Authored by sanjoy on Oct 12 2015, 9:30 PM.

Details

Summary

An unsigned comparision is equivalent to is corresponding signed version
if both the operands being compared are positive. Teach SCEV to use
this fact when profitable.

Diff Detail

Repository
rL LLVM

Event Timeline

sanjoy updated this revision to Diff 37213.Oct 12 2015, 9:30 PM
sanjoy retitled this revision from to [SCEV] Opportunistically interpret unsigned constraints as signed.
sanjoy updated this object.
sanjoy added reviewers: atrick, hfinkel, reames, nlewycky.
sanjoy added a subscriber: llvm-commits.
reames accepted this revision.Oct 14 2015, 11:20 AM
reames edited edge metadata.

LGTM w/comments addressed.

Q: Does InstCombine have similar logic? If it doesn't, it really should.

lib/Analysis/ScalarEvolution.cpp
7455 ↗(On Diff #37213)

I'm pretty sure this function already exists somewhere. If it doesn't, it should be a utility on ICmpInst or something.

7458 ↗(On Diff #37213)

Make this an assert? I'd rather see the calling code as isUnsignedCmp, followed by a call to this with an assert inside it. Less error prone.

7534 ↗(On Diff #37213)

This code is obviously correct, but it only handles one of the two cases immediately above it. I'd suggest in a separate change, pulling out the two cases above into a lambda, and then calling it twice, once with FoundPred, once with the signed compare if legal.

This revision is now accepted and ready to land.Oct 14 2015, 11:20 AM
sanjoy updated this revision to Diff 37386.Oct 14 2015, 1:56 PM
sanjoy marked 2 inline comments as done.
sanjoy edited edge metadata.
  • address review
lib/Analysis/ScalarEvolution.cpp
7455 ↗(On Diff #37213)

Moved to CmpInst::getSignedPredicate.

7534 ↗(On Diff #37213)

Good idea, I'll make a follow up patch doing this.

LGTM

include/llvm/IR/InstrTypes.h
1035 ↗(On Diff #37386)

I believe we're moving away from this style of doxygen comment even when in code surrounded by similar. the "/// brief. long" style has seemingly become the norm.

This revision was automatically updated to reflect the committed changes.