[LLVMbugs] [Bug 20049] New: load elimination do not occurs when source store is 2 potential alias (marked noalias) away

[bugzilla-daemon at llvm.org]

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: unassignedbugs at nondot.org
          Reporter: deadalnix at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140616/797d4033/attachment.html>