<html>
    <head>
      <base href="https://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 --- - Wrong code generation for VSX floating-point loads with fast-isel"
   href="https://llvm.org/bugs/show_bug.cgi?id=28630">28630</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Wrong code generation for VSX floating-point loads with fast-isel
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>libraries
          </td>
        </tr>

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

        <tr>
          <th>Hardware</th>
          <td>Other
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </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>Backend: PowerPC
          </td>
        </tr>

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

        <tr>
          <th>Reporter</th>
          <td>uweigand@de.ibm.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr></table>
      <p>
        <div>
        <pre>In some cases, fast-isel generates floating-point load instructions (lfd) with
an invalid register, like:
   lfd 36, ...
instead of using a VSX load instruction.  The wrong register number gets
silently truncated, causing invalid code to be generated.

Two source code examples showing this problem (clang at -O0):

1.) Loading a floating-point constant:

extern void checkd (double x, double v);

void
testd (double x01, double x02, double x03, double x04, double x05, double x06,
       double x07, double x08, double x09, double x10, double x11, double x12,
       double x13, double x14, double x15, double x16)
{
  checkd (x01, 1);
}

2.) Loading a floating-point global variable:

double g01d, g02d, g03d, g04d;
double g05d, g06d, g07d, g08d;
double g09d, g10d, g11d, g12d;
double g13d, g14d, g15d, g16d;

extern void testd (double x01, double x02, double x03, double x04, double x05,
                   double x06, double x07, double x08, double x09, double x10,
                   double x11, double x12, double x13, double x14, double x15,
                   double x16);

void
testitd (void)
{
  testd (g01d, g02d, g03d, g04d, g05d, g06d, g07d, g08d, g09d, g10d, g11d,
         g12d, g13d, g14d, g15d, g16d);
}


The issue can be detected more easily by enabling the -verify-machineinstrs llc
flag, which will detect the incorrect register class for the LFD result. 
Simplied IR test cases are:

1.) Loading a floating-point constant:

define double @test() {
  ret double 1.000000e+00
}

2.) Loading a floating-point global variable:

@g = common global double 0.000000e+00, align 8

define double @testitd() {
  %g = load double, double* @g, align 8
  ret double %g
}


I'm working on a couple of patches currently under test.</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>