[LLVMbugs] [Bug 15402] New: GlobalOpt creates giant initializers leading to excessively large object files

[bugzilla-daemon at llvm.org]

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

            Bug ID: 15402
           Summary: GlobalOpt creates giant initializers leading to
                    excessively large object files
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: sschiffli at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10112
  --> http://llvm.org/bugs/attachment.cgi?id=10112&action=edit
Reduced .ll file

This appears to be an optimization bug to me where GlobalOpt sacrifices file
size at any cost.

In the example I have a large array which was originally marked as
zeroinitializer, and store to the array in the c-tor chain.  When GlobalOpt
runs it builds a very large initializer of all zeros except for the one
non-zero value written in the c-tor chain.  Which results in a very large
object file just to initialize one element of this array.  To reproduce run
globalopt on the attached file.

For reference here is the original c++

int __attribute__((used)) bob[1000000];

int foo() {
    bob[10] = 99;
    return 0;
}

int x = foo();

int main() {
    return 0;
}

I was hoping to get some general advise as to the best way to do sparse data
initialization efficiently.  It seems the ELF itself sort of limits this due to
the contiguous nature of its sections, so any ideas would be appreciated.

-- 
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/20130228/444683db/attachment.html>