http://llvm.org/bugs/show_bug.cgi?id=20049
Bug ID: 20049
Summary: load elimination do not occurs when source store is 2
potential alias (marked noalias) away
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Global Analyses
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Classification: Unclassified
See sample IR bellow:
; ModuleID = 'test0156.d'
target datalayout =
"e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-f128:128:128-n8:16:32:64"
target triple = "x86_64-pc-linux-gnu"
%S1 = type { i32 }
%S2 = type { %S1*, i32 }
%S3 = type { %S2* }
define weak_odr i32 @_Dmain() {
body:
%0 = call noalias i8* @allocmemory(i64 4)
%1 = bitcast i8* %0 to %S1*
%a = getelementptr inbounds %S1* %1, i32 0, i32 0
store i32 11, i32* %a
%2 = call noalias i8* @allocmemory(i64 16)
%3 = bitcast i8* %2 to %S2*
%4 = getelementptr inbounds %S2* %3, i32 0, i32 0
store %S1* %1, %S1** %4
%b = getelementptr inbounds %S2* %3, i32 0, i32 1
store i32 25, i32* %b
%5 = call noalias i8* @allocmemory(i64 8)
%6 = bitcast i8* %5 to %S3*
%7 = getelementptr inbounds %S3* %6, i32 0, i32 0
store %S2* %3, %S2** %7
%8 = load i32* %a
%9 = load i32* %b
%10 = add i32 %8, %9
ret i32 %10
}
declare noalias i8* @allocmemory(i64)
opt -O3 is capable of optimizing the %9 = load i32* %b away, but not the %8 =
load i32* %a , presumably because the optimizer think it may alias, abeit both
memory allocation being marked as noalias.
This kind of code is fairly common in functional style D code (it result of
closure being inlined in caller). This tends to cascade down to pretty bad code
generation as memory allocation looks alive and can't be optimized away by D
specific passes, resulting in closure being allocated on the heap when they
shouldn't exist at all.
I'd assume this kind of problem would also occurs on functional languages in
general.
For reference it optimizes as:
; ModuleID = '<stdin>'
target datalayout =
"e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-f128:128:128-n8:16:32:64"
target triple = "x86_64-pc-linux-gnu"
%S1 = type { i32 }
%S2 = type { %S1*, i32 }
define weak_odr i32 @_Dmain() {
body:
%0 = tail call noalias i8* @allocmemory(i64 4)
%1 = bitcast i8* %0 to %S1*
%a = bitcast i8* %0 to i32*
store i32 11, i32* %a, align 4
%2 = tail call noalias i8* @allocmemory(i64 16)
%3 = bitcast i8* %2 to %S2*
%4 = bitcast i8* %2 to %S1**
store %S1* %1, %S1** %4, align 8
%b = getelementptr inbounds i8* %2, i64 8
%5 = bitcast i8* %b to i32*
store i32 25, i32* %5, align 4
%6 = tail call noalias i8* @allocmemory(i64 8)
%7 = bitcast i8* %6 to %S2**
store %S2* %3, %S2** %7, align 8
%8 = load i32* %a, align 4
%9 = add i32 %8, 25
ret i32 %9
}
declare noalias i8* @allocmemory(i64)
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
