[LLVMbugs] [Bug 15857] New: BB vectorization: wrongly selected vectorization pair breaks load/store order

[bugzilla-daemon at llvm.org]

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

            Bug ID: 15857
           Summary: BB vectorization: wrongly selected vectorization pair
                    breaks load/store order
           Product: new-bugs
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dtakahashi42 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

With the Basic Block vectorization, llvm can fuse multiple store instructions
into a vector instruction. However, it sometimes misses to find the depending
load instructions, and reverses the order of the load and the store
instructions.

The attached c-source and .ll testcase indicates this problem. After the BB
vectorization pass, the llvm assembly of,
  store double %sub3, double* %x, align 8                       ; 1.1
  store double 1.000000e+00, double* %y, align 8
  %0 = load double* %x, align 8                                 ; 1.2
  %arrayidx6 = getelementptr inbounds double* %x, i64 1
  store double %0, double* %arrayidx6, align 8                  ; 1.3
is transformed to,
  %0 = bitcast double* %x to <2 x double>*
  store double 1.000000e+00, double* %y, align 8
  %1 = load double* %x, align 8                                 ; 2.1
  %2 = insertelement <2 x double> undef, double %sub3, i32 0
  %3 = insertelement <2 x double> %2, double %1, i32 1
  store <2 x double> %3, <2 x double>* %0, align 8              ; 2.2
Before the optimization, %x is stored before its load (1.1 and 1.2), but after
then, the store instruction is fused to another store (1.3) and moved to the
last (2.2). As a result, the load instruction (2.1) loads an undesirable value.
I would like to make a simpler test case, but I could not do it because the
generated code is highly sensitive to the combination of optimization flags and
the lest of code.

-- 
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/20130427/3a0bff9c/attachment.html>