maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Transforms/InstCombine/2012-07-25-LoadPart.ll

13 lines
453 B
LLVM
Raw Normal View History

When folding a load from a global constant, if the load started in the middle of an array element (rather than at the beginning of the element) and extended into the next element, then the load from the second element was being handled wrong due to incorrect updating of the notion of which byte to load next. This fixes PR13442. Thanks to Chris Smowton for reporting the problem, analyzing it and providing a fix. llvm-svn: 160711
2012-07-25 17:14:54 +08:00
; RUN: opt < %s -instcombine -S | FileCheck %s
; PR13442
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S128"
@test = constant [4 x i32] [i32 1, i32 2, i32 3, i32 4]
define i64 @foo() {
Don't perform an overaligned load in this test, since that's undefined behaviour that might be exploited one day. llvm-svn: 160714
2012-07-25 17:45:37 +08:00
%ret = load i64* bitcast (i8* getelementptr (i8* bitcast ([4 x i32]* @test to i8*), i64 2) to i64*), align 1
When folding a load from a global constant, if the load started in the middle of an array element (rather than at the beginning of the element) and extended into the next element, then the load from the second element was being handled wrong due to incorrect updating of the notion of which byte to load next. This fixes PR13442. Thanks to Chris Smowton for reporting the problem, analyzing it and providing a fix. llvm-svn: 160711
2012-07-25 17:14:54 +08:00
ret i64 %ret
; CHECK: ret i64 844424930263040
}