llvm-6502/test/Transforms/IndVarSimplify/preserve-gep-remainder.ll
Andrew Trick 5fd5b125ff Avoid creating canonical induction variables for non-native types.
For example, on 32-bit architecture, don't promote all uses of the IV
to 64-bits just because one use is a 64-bit cast.
Alternate implementation of the patch by Arnaud de Grandmaison.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127884 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-18 16:50:32 +00:00

21 lines
775 B
LLVM

; RUN: opt < %s -indvars -S \
; RUN: | grep {\[%\]p.2.ip.1 = getelementptr \\\[3 x \\\[3 x double\\\]\\\]\\* \[%\]p, i64 2, i64 \[%\]tmp, i64 1}
target datalayout = "E-p:64:64:64-a0:0:8-f32:32:32-f64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-v64:64:64-v128:128:128-n:32:64"
; Indvars shouldn't expand this to
; %p.2.ip.1 = getelementptr [3 x [3 x double]]* %p, i64 0, i64 %tmp, i64 19
; or something. That's valid, but more obscure.
define void @foo([3 x [3 x double]]* noalias %p) nounwind {
entry:
br label %loop
loop:
%i = phi i64 [ 0, %entry ], [ %i.next, %loop ]
%ip = add i64 %i, 1
%p.2.ip.1 = getelementptr [3 x [3 x double]]* %p, i64 2, i64 %ip, i64 1
volatile store double 0.0, double* %p.2.ip.1
%i.next = add i64 %i, 1
br label %loop
}