[LLVMbugs] [Bug 15200] New: alloca scalarization with dynamic indexing into vectors deletes stores

[bugzilla-daemon at llvm.org]

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

            Bug ID: 15200
           Summary: alloca scalarization with dynamic indexing into
                    vectors deletes stores
           Product: new-bugs
           Version: 3.2
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: elnino2324 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 9978
  --> http://llvm.org/bugs/attachment.cgi?id=9978&action=edit
example case running -scalarrepl

I see that in the ScalarReplAggregates pass in the LLVM 3.2 release the call
SROA::isSafeGEP() will now allow alloca scalarization in the case where a GEP
index into a vector isn’t a constant.  I have an example .ll where we have an
alloca that can potentially be scalarized where the index into the vector is a
function argument and could be set to any value.

In the attached example, the sequence of stores is copying the data from %src
into %sPrivateStorage with the GEP of interest being:

  %add.ptr = getelementptr inbounds [3 x <2 x i32>]* %sPrivateStorage, i64 0,
i64 0, i64 %idx.ext

After running the line:

opt.exe -scalarrepl scalar_repl_store_delete.ll
-o=scalar_repl_store_delete_after.bc

we get the bottom result in the attachment.  The second two stores are deleted
because they appear to be dead even though that data can actually be reached by
the out of bounds vector index in the GEP.  I would expect the stores to be
untouched so that the data from %src gets copied over to %sPrivateStorage.

-- 
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/20130207/b8ed1f54/attachment.html>