Resolving a branch allows us to ignore blocks that won't be executed, and thus make our estimate more accurate.
This patch is intended to be applied after D10205 (though it could be applied independently).
Details
Diff Detail
Event Timeline
- In two-operand instructions use simplified values only if both operands have the same base pointer (or don't have it at all).
Totally the right direction, just some quick comments here. This patch will likely change some based on my comments in D10205 but these are independent issues.
lib/Transforms/Scalar/LoopUnrollPass.cpp | ||
---|---|---|
528–529 | I don't think the 'Cond' variable is buying you much. I would also write the condition differently as the only null case is where we have no simplified value. The type must always be an int. So: if (Constant *SimpleCond = SimplifiedValues.lookup(BI->getCondition())) { BBWorklist.insert(BI->getSuccessor(cast<ConstantInt>(SimpleCond)->isZero() ? 1 : 0)); | |
535–538 | Same comment as above. |
- Rebase.
- Rename SCEVSimplify to simplifyInstWithSCEV in visitCmpInst.
- Fallback to Base visitor if failed to constant fold (and only then call simplifyInstWithSCEV).
- Rewrite conditional expression for adding successors.
Looks really close, just need to sort out the offset simplification.
lib/Transforms/Scalar/LoopUnrollPass.cpp | ||
---|---|---|
367–369 | This doesn't really seem correct to me... For example, multiplication such as "(B + X) * (B + Y)" does not simplify to "X * Y". Even addition doesn't simplify that way. I think it would be more clear (and correct) to explicitly handle the math that simplifies here rather than trying to share a routine. Test for subtraction and that LHS and RHS are in the simplified addresses mapping. If they are, you can write a comment about how the base addresses cancel and the result is the CaonstantExpr difference of the offsets. I don't think you really need to even think about falling through to the fancy InstSimplify logic here because you only can do anything when you have boring constant offsets. | |
434 | If you take my advice above, I would also inline the logic here. I'm not sure there is really going to be that much shared between the two when you're done. You can really *only* handle subtraction above, but here you can handle any comparison and really want to just fall back on the same logic. | |
543 | I would leave a hint in this comment that this is the fallback if we can't directly fold the successor above. |
Address review remarks:
- Add tests.
- Remove simplifyUsingOffsets routine.
- .. and rebase on the trunk.
Hi Chandler,
I updated the patch - does it look good now?
I decided not to handle operands in (Base+Offset) form in visitBinaryOperator for now, because I think we could get into troubles even if we only look at SUB (I'm concerned about possible overflow errors here). I think it's possible to do, but we can do it later if we ever need it.
Tests are also added to the patch now (mostly they are from D10208).
Thanks,
Michael
This looks fantastic. Nit-picky indenting and layout below. Feel free to commit with that addressed.
lib/Transforms/Scalar/LoopUnrollPass.cpp | ||
---|---|---|
436–444 | I actually think its better to nest these. Because we're using fall-through to "continue trying", the early-exit is hard to spot here. It also will save some map lookups: auto SimplifiedLHS = SimplifiedAddresses.find(LHS) if (SimplifiedLHS != SimplifiedAddresses.end()) { auto SimplifiedRHS = SimplifiedAddresses.find(RHS); if (SimplifiedRHS != SimplifiedAddresses.end()) { SimplifiedAddress &LHSAddr = SimplifiedLHS->second; SimplifiedAddress &RHSAddr = SimplifiedRHS->second; if (LHSAddr.Base == RHSAddr.Base) { LHS = LHSAddr.Offset; ... | |
447–449 | If you're going to skip the middle {}s (which I'm fine with) skip the outer ones as well. |
This doesn't really seem correct to me...
For example, multiplication such as "(B + X) * (B + Y)" does not simplify to "X * Y". Even addition doesn't simplify that way.
I think it would be more clear (and correct) to explicitly handle the math that simplifies here rather than trying to share a routine. Test for subtraction and that LHS and RHS are in the simplified addresses mapping. If they are, you can write a comment about how the base addresses cancel and the result is the CaonstantExpr difference of the offsets.
I don't think you really need to even think about falling through to the fancy InstSimplify logic here because you only can do anything when you have boring constant offsets.