forked from OSchip/llvm-project
SCEVExpander incorrectly marks generated subtractions as nuw/nsw
It is not sound to mark the increment operation as `nuw` or `nsw` based on a proof off of the add recurrence if the increment operation we emit happens to be a `sub` instruction. I could not come up with a test case for this -- the cases where SCEVExpander decides to emit a `sub` instruction is quite small, and I cannot think of a way I'd be able to get SCEV to prove that the increment does not overflow in those cases. Differential Revision: http://reviews.llvm.org/D7899 llvm-svn: 230673
This commit is contained in:
parent
fa147e02d8
commit
54ef895137
|
@ -1182,9 +1182,6 @@ SCEVExpander::getAddRecExprPHILiterally(const SCEVAddRecExpr *Normalized,
|
|||
}
|
||||
}
|
||||
|
||||
bool IncrementIsNUW = IsIncrementNUW(SE, Normalized);
|
||||
bool IncrementIsNSW = IsIncrementNSW(SE, Normalized);
|
||||
|
||||
// Save the original insertion point so we can restore it when we're done.
|
||||
BuilderType::InsertPointGuard Guard(Builder);
|
||||
|
||||
|
@ -1219,6 +1216,12 @@ SCEVExpander::getAddRecExprPHILiterally(const SCEVAddRecExpr *Normalized,
|
|||
// Expand the step somewhere that dominates the loop header.
|
||||
Value *StepV = expandCodeFor(Step, IntTy, L->getHeader()->begin());
|
||||
|
||||
// The no-wrap behavior proved by IsIncrement(NUW|NSW) is only applicable if
|
||||
// we actually do emit an addition. It does not apply if we emit a
|
||||
// subtraction.
|
||||
bool IncrementIsNUW = !useSubtract && IsIncrementNUW(SE, Normalized);
|
||||
bool IncrementIsNSW = !useSubtract && IsIncrementNSW(SE, Normalized);
|
||||
|
||||
// Create the PHI.
|
||||
BasicBlock *Header = L->getHeader();
|
||||
Builder.SetInsertPoint(Header, Header->begin());
|
||||
|
|
Loading…
Reference in New Issue