[llvm-bugs] [Bug 32548] New: [LSR] LSR is producing bad code

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=32548

            Bug ID: 32548
           Summary: [LSR]  LSR is producing bad code
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: paulsson at linux.vnet.ibm.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18234
  --> https://bugs.llvm.org/attachment.cgi?id=18234&action=edit
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

-- 
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/20170406/63af77c1/attachment.html>