<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </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 - [LSR] LSR is producing bad code"
   href="https://bugs.llvm.org/show_bug.cgi?id=32548">32548</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>[LSR]  LSR is producing bad code
          </td>
        </tr>

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

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

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </td>
        </tr>

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

        <tr>
          <th>Severity</th>
          <td>enhancement
          </td>
        </tr>

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

        <tr>
          <th>Component</th>
          <td>Loop Optimizer
          </td>
        </tr>

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

        <tr>
          <th>Reporter</th>
          <td>paulsson@linux.vnet.ibm.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Created <span class=""><a href="attachment.cgi?id=18234" name="attach_18234" title="reduced test case">attachment 18234</a> <a href="attachment.cgi?id=18234&action=edit" title="reduced test case">[details]</a></span>
reduced test case

In the spirit of healthy competition between gcc and llvm, I have found a a
regression on a benchmark. At least one of the problems is that LSR is not
producing good code (while gcc indeed does).

On SystemZ, some memory instructions only support immediate offset of 12 bits.
This is the reason for the hook isFoldableMemAccessOffset(), which adds extra
cost if the offset does not fit.

This hook isn't enough to help this test case. LSR produces big offsets even as
extra costs are added for them. I tried adding experimental big costs, and even
tried incrementing NumRegs in LSR when such an offset was present, but this did
not help. I suspect that either the right formula isn't generated in the first
place, or there is some other heuristic that unfortunately takes precedence
somehow.

The cost on SystemZ for a too big offset for a memory access is one extra
instruction to add the offset.

I would appreciate any help on this,

Jonas

Run with:
bin/llc -mtriple=s390x-linux-gnu -mcpu=z13</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>