[LLVMbugs] [Bug 6642] New: Loads from arrays initialized with a single large store not optimized

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=6642

           Summary: Loads from arrays initialized with a single large
                    store not optimized
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matti.niemenmaa+llvmbugs at iki.fi
                CC: llvmbugs at cs.uiuc.edu


The following IR is optimized by 'opt -std-compile-opts -std-link-opts' from
r98773 to a main that simply returns zero:


target datalayout =
"e-p:64:64:64-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"
target triple = "x86_64-unknown-linux-gnu"

%ARRAY = type [128 x i8]

define i32 @main() nounwind readnone {
    %x = alloca %ARRAY, align 16
    store %ARRAY zeroinitializer, %ARRAY* %x, align 16
    %y = getelementptr inbounds %ARRAY* %x, i64 0, i64 0
    %z = load i8* %y, align 16
    %w = zext i8 %z to i32
    ret i32 %w
}


But if we change %ARRAY to be something bigger, like %ARRAY = type [256 x i8],
the code passes through the optimizer unchanged. 128 is the exact bound in this
case: 129 and anything larger inhibits optimization.

Initializing each element of %x individually (lots of separate geps and stores)
apparently works regardless of the size of %ARRAY, but it's a shame that this
seemingly cleaner code optimizes so poorly.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.