IVUsers should only generate SCEV's for values that are safe to speculate.

This allows SCEVExpander to run on the IV expressions.

This codifies an assumption made by LSR to complete the fix for
PR11356, but I haven't been able to generate a separate unit test for
this part. I'm adding it as an extra safety check.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160204 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Andrew Trick 2012-07-13 23:33:05 +00:00
parent 8b7036b0f4
commit 31f61e8b22

View File

@ -21,6 +21,7 @@
#include "llvm/Analysis/Dominators.h"
#include "llvm/Analysis/LoopPass.h"
#include "llvm/Analysis/ScalarEvolutionExpressions.h"
#include "llvm/Analysis/ValueTracking.h"
#include "llvm/Target/TargetData.h"
#include "llvm/Assembly/Writer.h"
#include "llvm/ADT/STLExtras.h"
@ -120,6 +121,12 @@ bool IVUsers::AddUsersImpl(Instruction *I,
if (!SE->isSCEVable(I->getType()))
return false; // Void and FP expressions cannot be reduced.
// IVUsers is used by LSR which assumes that all SCEV expressions are safe to
// pass to SCEVExpander. Expressions are not safe to expand if they represent
// operations that are not safe to speculate, namely integer division.
if (!isa<PHINode>(I) && !isSafeToSpeculativelyExecute(I, TD))
return false;
// LSR is not APInt clean, do not touch integers bigger than 64-bits.
// Also avoid creating IVs of non-native types. For example, we don't want a
// 64-bit IV in 32-bit code just because the loop has one 64-bit cast.