[llvm-bugs] [Bug 31063] New: MergeConsecutiveStores fails in presence of preceding load

[via llvm-bugs]

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

            Bug ID: 31063
           Summary: MergeConsecutiveStores fails in presence of preceding
                    load
           Product: libraries
           Version: 3.9
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: djones at xtreme-eda.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 17613
  --> https://llvm.org/bugs/attachment.cgi?id=17613&action=edit
IR illustrating bug

The attached IR file defines two functions test_func, and test_func3.  These
functions perform consecutive stores of constants, and expect the backend to
combine the byte stores into a larger store.

Using LLVM 3.9.0 release on x86-64 Debian Linux, I get:

        .text
        .file   "test.ll"
        .globl  test_func
        .p2align        4, 0x90
        .type   test_func, at function
test_func:                              # @test_func
        .cfi_startproc
# BB#0:                                 # %bb_1
        movw    $770, 80(%rdi)          # imm = 0x302
        xorl    %eax, %eax
        retq
.Lfunc_end0:
        .size   test_func, .Lfunc_end0-test_func
        .cfi_endproc

        .globl  test_func3
        .p2align        4, 0x90
        .type   test_func3, at function
test_func3:                             # @test_func3
        .cfi_startproc
# BB#0:                                 # %bb_1
        movq    (%rdi), %rax
        movb    $4, 80(%rax)
        movb    $5, 81(%rax)
        xorl    %eax, %eax
        retq
.Lfunc_end1:
        .size   test_func3, .Lfunc_end1-test_func3
        .cfi_endproc

The stores were merged for the first case, but not the second.  The only
difference between the two is that in the second case, there is a preceding
load, which may alias the stores.  If this load occurred in between the stores,
then it is clear that combining the stores is wrong, as you ought not to move
stores around a possibly aliasing load. However, this is not the case here: the
stores follow the load, and combining them will not affect the load.

-- 
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/20161118/9e2f6f67/attachment.html>