[LLVMbugs] [Bug 23768] New: Machine CSE removes register-defining LDM, causing assertion failure

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Jun 5 07:54:56 PDT 2015


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

            Bug ID: 23768
           Summary: Machine CSE removes register-defining LDM, causing
                    assertion failure
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: john.brawn.123 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 14440
  --> https://llvm.org/bugs/attachment.cgi?id=14440&action=edit
Input IR that causes the assertion failure

Compiling the attached bugpoint-reduced-simplified.ll with trunk (r239136) llc
causes the assertion failure

lib/CodeGen/LiveVariables.cpp:133: void
llvm::LiveVariables::HandleVirtRegUse(unsigned int, llvm::MachineBasicBlock*,
llvm::MachineInstr*): Assertion `MRI->getVRegDef(reg) && "Register use before
def!"' failed.

This has started happening since r238473, when the ARM backend started lowering
memcpy->MCOPY->LDM+STM, but what's causing the assertion failure is that
Machine CSE is getting this input:

BB#0: derived from LLVM BB %testArray.exit.critedge
    %vreg0<def> = tLDRpci <cp#0>, pred:14, pred:%noreg; mem:LD4[ConstantPool]
tGPR:%vreg0
    %vreg1<def> = tLDRpci <cp#1>, pred:14, pred:%noreg; mem:LD4[ConstantPool]
tGPR:%vreg1
    %vreg3<def,tied1> = tLDMIA_UPD %vreg0<tied0>, pred:14, pred:%noreg,
%vreg4<def>, %vreg5<def>, %vreg6<def>; tGPR:%vreg3,%vreg0,%vreg4,%vreg5,%vreg6
    %vreg2<def,tied1> = tSTMIA_UPD %vreg1<tied0>, pred:14, pred:%noreg,
%vreg4<kill>, %vreg5<kill>, %vreg6<kill>;
tGPR:%vreg2,%vreg1,%vreg4,%vreg5,%vreg6
    %vreg8<def,tied1> = tLDMIA_UPD %vreg3<kill,tied0>, pred:14, pred:%noreg,
%vreg9<def>, %vreg10<def>, %vreg11<def>;
tGPR:%vreg8,%vreg3,%vreg9,%vreg10,%vreg11
    %vreg7<def,tied1> = tSTMIA_UPD %vreg2<kill,tied0>, pred:14, pred:%noreg,
%vreg9<kill>, %vreg10<kill>, %vreg11<kill>;
tGPR:%vreg7,%vreg2,%vreg9,%vreg10,%vreg11
    %vreg13<def,tied1> = tLDMIA_UPD %vreg0<tied0>, pred:14, pred:%noreg,
%vreg14<def>, %vreg15<def>, %vreg16<def>;
tGPR:%vreg13,%vreg0,%vreg14,%vreg15,%vreg16
    %vreg12<def,tied1> = tSTMIA_UPD %vreg1<tied0>, pred:14, pred:%noreg,
%vreg14<kill>, %vreg15<kill>, %vreg16<kill>;
tGPR:%vreg12,%vreg1,%vreg14,%vreg15,%vreg16
    %vreg18<def,tied1> = tLDMIA_UPD %vreg13<kill,tied0>, pred:14, pred:%noreg,
%vreg19<def>, %vreg20<def>, %vreg21<def>;
tGPR:%vreg18,%vreg13,%vreg19,%vreg20,%vreg21
    %vreg17<def,tied1> = tSTMIA_UPD %vreg12<kill,tied0>, pred:14, pred:%noreg,
%vreg19<kill>, %vreg20<kill>, %vreg21<kill>;
tGPR:%vreg17,%vreg12,%vreg19,%vreg20,%vreg21
    tBX_RET pred:14, pred:%noreg

It then does the following optimisation:

Examining: %vreg13<def,tied1> = tLDMIA_UPD %vreg0<tied0>, pred:14, pred:%noreg,
%vreg14<def>, %vreg15<def>, %vreg16<def>;
tGPR:%vreg13,%vreg0,%vreg14,%vreg15,%vreg16
*** Found a common subexpression: %vreg3<def,tied1> = tLDMIA_UPD %vreg0<tied0>,
pred:14, pred:%noreg, %vreg4<def>, %vreg5<def>, %vreg6<def>;
tGPR:%vreg3,%vreg0,%vreg4,%vreg5,%vreg6
Examining: %vreg18<def,tied1> = tLDMIA_UPD %vreg3<tied0>, pred:14, pred:%noreg,
%vreg19<def>, %vreg20<def>, %vreg21<def>;
tGPR:%vreg18,%vreg3,%vreg19,%vreg20,%vreg21
*** Found a common subexpression: %vreg8<def,tied1> = tLDMIA_UPD %vreg3<tied0>,
pred:14, pred:%noreg, %vreg9<def>, %vreg10<def>, %vreg11<def>;
tGPR:%vreg8,%vreg3,%vreg9,%vreg10,%vreg11

giving the result

BB#0: derived from LLVM BB %testArray.exit.critedge
    %vreg0<def> = tLDRpci <cp#0>, pred:14, pred:%noreg; mem:LD4[ConstantPool]
tGPR:%vreg0
    %vreg1<def> = tLDRpci <cp#1>, pred:14, pred:%noreg; mem:LD4[ConstantPool]
tGPR:%vreg1
    %vreg3<def,tied1> = tLDMIA_UPD %vreg0<tied0>, pred:14, pred:%noreg,
%vreg4<def>, %vreg5<def>, %vreg6<def>; tGPR:%vreg3,%vreg0,%vreg4,%vreg5,%vreg6
    %vreg2<def,tied1> = tSTMIA_UPD %vreg1<tied0>, pred:14, pred:%noreg,
%vreg4<kill>, %vreg5<kill>, %vreg6<kill>;
tGPR:%vreg2,%vreg1,%vreg4,%vreg5,%vreg6
    %vreg8<def,tied1> = tLDMIA_UPD %vreg3<tied0>, pred:14, pred:%noreg,
%vreg9<def>, %vreg10<def>, %vreg11<def>;
tGPR:%vreg8,%vreg3,%vreg9,%vreg10,%vreg11
    %vreg7<def,tied1> = tSTMIA_UPD %vreg2<kill,tied0>, pred:14, pred:%noreg,
%vreg9<kill>, %vreg10<kill>, %vreg11<kill>;
tGPR:%vreg7,%vreg2,%vreg9,%vreg10,%vreg11
    %vreg12<def,tied1> = tSTMIA_UPD %vreg1<tied0>, pred:14, pred:%noreg,
%vreg14<kill>, %vreg15<kill>, %vreg16<kill>;
tGPR:%vreg12,%vreg1,%vreg14,%vreg15,%vreg16
    %vreg17<def,tied1> = tSTMIA_UPD %vreg12<kill,tied0>, pred:14, pred:%noreg,
%vreg19<kill>, %vreg20<kill>, %vreg21<kill>;
tGPR:%vreg17,%vreg12,%vreg19,%vreg20,%vreg21
    tBX_RET pred:14, pred:%noreg

Virtual registers 14-16 and 19-21 now have no definition, leading to the above
assertion failure.

-- 
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/20150605/9d4a23cc/attachment.html>


More information about the llvm-bugs mailing list