<html>
    <head>
      <base href="http://llvm.org/bugs/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - BB vectorization: wrongly selected vectorization pair breaks load/store order"
   href="http://llvm.org/bugs/show_bug.cgi?id=15857">15857</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>BB vectorization: wrongly selected vectorization pair breaks load/store order
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>new-bugs
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>trunk
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>Macintosh
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>MacOS X
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>new bugs
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>dtakahashi42@gmail.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvmbugs@cs.uiuc.edu
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr></table>
      <p>
        <div>
        <pre>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.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>