mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-26 04:32:44 +01:00
49b37e626b
This is a re-application of a r303497 that was reverted in r303498. I thought it had broken a bot when it had not (the breakage did not go away with the revert). This change makes the split between the "exact" backedge taken count and the "maximum" backedge taken count a bit more obvious. Both of these are upper bounds on the number of times the loop header executes (since SCEV does not account for most kinds of abnormal control flow), but the latter is guaranteed to be a constant. There were a few places where the max backedge taken count *was* a non-constant; I've changed those to compute constants instead. At this point, I'm not sure if the constant max backedge count can be computed by calling `getUnsignedRange(Exact).getUnsignedMax()` without losing precision. If it can, we can simplify even further by making `getMaxBackedgeTakenCount` a thin wrapper around `getBackedgeTakenCount` and `getUnsignedRange`. llvm-svn: 303531 |
||
---|---|---|
.. | ||
AliasSet | ||
AssumptionCache | ||
BasicAA | ||
BlockFrequencyInfo | ||
BranchProbabilityInfo | ||
CallGraph | ||
CFLAliasAnalysis | ||
ConstantFolding | ||
CostModel | ||
Delinearization | ||
DemandedBits | ||
DependenceAnalysis | ||
DivergenceAnalysis | ||
DominanceFrontier | ||
Dominators | ||
GlobalsModRef | ||
IVUsers | ||
LazyCallGraph | ||
LazyValueAnalysis | ||
Lint | ||
LoopAccessAnalysis | ||
LoopInfo | ||
MemoryDependenceAnalysis | ||
MemorySSA | ||
PostDominators | ||
ProfileSummary | ||
RegionInfo | ||
ScalarEvolution | ||
ScopedNoAliasAA | ||
TypeBasedAliasAnalysis | ||
ValueTracking | ||
alias-analysis-uses.ll |