[llvm-bugs] [Bug 25310] New: [DAGCombiner] missed transfer of chain edge

[via llvm-bugs]

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

            Bug ID: 25310
           Summary: [DAGCombiner] missed transfer of chain edge
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: paulsson at linux.vnet.ibm.com
                CC: llvm-bugs at lists.llvm.org, Matthew.Arsenault at amd.com
    Classification: Unclassified

Created attachment 15154
  --> https://llvm.org/bugs/attachment.cgi?id=15154&action=edit
llc input

I think I have found a bug in DAGCombiner, where two stores and two loads get
combined to wider variants in DAGCombiner::MergeConsecutiveStores().
The problem is that the there was another third store that aliased one of the
loads, but this other store does not get an updated chain dependency to the
new load.

(sorry for line breaks - please copy and paste into an editor if needed)
before MergeConsecutiveStores(t49):

SelectionDAG has 44 nodes:
  t0: ch = EntryToken
  t2: i64,ch = CopyFromReg t0, Register:i64 %vreg12
  t4: i64,ch = CopyFromReg t0, Register:i64 %vreg13
  t6: i64 = add t2, Constant:i64<-4>
  t7: i64 = Constant<0>
  t9: i32,ch = load<LD4[%scevgep14](tbaa=<0x2414008>)> t0, t6, undef:i64
  t10: i32,ch = load<LD4[%lsr.iv1012](tbaa=<0x2414008>)> t0, t2, undef:i64
  t11: i64 = add t4, Constant:i64<-4>
  t12: i32,ch = load<LD4[%scevgep7](tbaa=<0x2414008>)> t0, t11, undef:i64      
        <<<<<<<<
  t13: i32,ch = load<LD4[%lsr.iv35](tbaa=<0x2414008>)> t0, t4, undef:i64       
        <<<<<<<<
    t28: i32,ch = CopyFromReg t0, Register:i32 %vreg11
  t30: i32 = add t28, Constant:i32<1>
      t14: ch = TokenFactor t9:1, t10:1, t12:1, t13:1
    t15: ch = store<ST4[%scevgep6](tbaa=<0x2414008>)> t14, t9, t11, undef:i64
      t48: ch = TokenFactor t9:1, t10:1, t13:1                                
    t51: ch = store<ST4[%lsr.iv35](tbaa=<0x2414008>)> t48, t10, t4, undef:i64  
<<< // Other store chained after t13
  t52: ch = TokenFactor t15, t51
          t20: i64 = add t4, Constant:i64<8>
        t22: ch = CopyToReg t0, Register:i64 %vreg14, t20
          t24: i64 = add t2, Constant:i64<256>
        t26: ch = CopyToReg t0, Register:i64 %vreg15, t24
        t32: ch = CopyToReg t0, Register:i32 %vreg16, t30
          t17: ch = store<ST4[%scevgep13](tbaa=<0x2414008>)> t52, t12, t6,
undef:i64     <<<<<<<<
          t49: ch = store<ST4[%lsr.iv1012](tbaa=<0x2414008>)> t52, t13, t2,
undef:i64    <<<<<<<<
        t50: ch = TokenFactor t17, t49
      t41: ch = TokenFactor t22, t26, t32, t50
      t34: i32,ch = CopyFromReg t0, Register:i32 %vreg10
    t47: ch = br_cc t41, setne:ch, t34, t30, BasicBlock:ch<for.body.3.i
0x249ce30>
  t44: ch = br t47, BasicBlock:ch<for.inc.40.i 0x249d000>


After MergeConsecutiveStores(t49), the t13 chain has been dropped but not
replaced.

      t48: ch = TokenFactor t9:1, t10:1, t0
    t51: ch = store<ST4[%lsr.iv35](tbaa=<0x2414008>)> t48, t10, t4, undef:i64

I would have expected MergeConsecutiveStores() to transfer the sum of the chain
users of the loads to the new load, but
this does not appear to happen (It would also have been nice to get a debug
output when replacing the loads).

The test case is
projects/test-suite/SingleSource/Regression/C/Output/matrixTranspose, which
shows up as a test fail on SystemZ.

llc -O3 matrixTranspose.linked.bc -mtriple=s390x-linux-gnu

// DAG: BB#5 'main:for.body.3.i'

// Source code: projects/test-suite/SingleSource/Regression/C/matrixTranspose.c

-- 
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/20151025/4d7ec6b0/attachment-0001.html>