[LLVMbugs] [Bug 14431] New: Missed opportunity for dead store elimination

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Nov 24 11:11:13 PST 2012


http://llvm.org/bugs/show_bug.cgi?id=14431

             Bug #: 14431
           Summary: Missed opportunity for dead store elimination
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Global Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: craig.topper at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


While looking at some generated code from a bootstrap build.

I noticed this sequence of code
    SDValue Ops[6];
    Ops[0] = getRoot();
    Ops[1] = getValue(I.getArgOperand(0));
    Ops[2] = getValue(I.getArgOperand(1));
    Ops[3] = getValue(I.getArgOperand(2));
    Ops[4] = DAG.getSrcValue(I.getArgOperand(0));
    Ops[5] = DAG.getSrcValue(F);

    Res = DAG.getNode(ISD::INIT_TRAMPOLINE, dl, MVT::Other, Ops, 6);

Generated this assembly:
    movq    $0, -2272(%rbp)
    movl    $0, -2264(%rbp)
    movq    $0, -2256(%rbp)
    movl    $0, -2248(%rbp)
    movq    $0, -2240(%rbp)
    movl    $0, -2232(%rbp)
    movq    $0, -2224(%rbp)
    movl    $0, -2216(%rbp)
    movq    $0, -2208(%rbp)
    movl    $0, -2200(%rbp)
    movq    $0, -2192(%rbp)
    movl    $0, -2184(%rbp)
    movq    %r12, %rdi
    callq    __ZN4llvm19SelectionDAGBuilder7getRootEv
    movq    %rax, -2272(%rbp)
    movl    %edx, -2264(%rbp)
    movl    48(%rbx), %eax
    negq    %rax
    leaq    (%rax,%rax,2), %rax
    movq    (%rbx,%rax,8), %rsi
    movq    %r12, %rdi
    callq    __ZN4llvm19SelectionDAGBuilder8getValueEPKNS_5ValueE
    movq    %rax, -2256(%rbp)
    movl    %edx, -2248(%rbp)
    movl    48(%rbx), %eax
    subq    %rax, %r15
    leaq    (%r15,%r15,2), %rax
    movq    (%rbx,%rax,8), %rsi
    movq    %r12, %rdi
    callq    __ZN4llvm19SelectionDAGBuilder8getValueEPKNS_5ValueE
    movl    $2, %ecx
    movq    %rax, -2240(%rbp)
    movl    %edx, -2232(%rbp)
    movl    48(%rbx), %eax
    subq    %rax, %rcx
    leaq    (%rcx,%rcx,2), %rax
    movq    (%rbx,%rax,8), %rsi
    movq    %r12, %rdi
    callq    __ZN4llvm19SelectionDAGBuilder8getValueEPKNS_5ValueE
    movq    %rax, -2224(%rbp)
    movl    %edx, -2216(%rbp)
    movl    48(%rbx), %eax
    negq    %rax
    leaq    (%rax,%rax,2), %rax
    movq    (%rbx,%rax,8), %rsi
    movq    408(%r12), %rdi
    callq    __ZN4llvm12SelectionDAG11getSrcValueEPKNS_5ValueE
    movq    %rax, -2208(%rbp)
    movl    %edx, -2200(%rbp)
    movq    408(%r12), %rdi
    movq    %r14, %rsi
    callq    __ZN4llvm12SelectionDAG11getSrcValueEPKNS_5ValueE
    movq    $0, -4832(%rbp)         ## 8-byte Folded Spill
    leaq    -2272(%rbp), %r9
    movq    %rax, -2192(%rbp)
    movl    %edx, -2184(%rbp)


You'll see at the start of the assembly there are 12 stores of 0 to initialize
the SDValue array. But each of those values are overwritten by the getRoot,
getValue, getSrcValue calls. Dead store elimination should have been able to
remove the stores of 0.


As far as I can tell this didn't happen because alias analysis thinks that
getRoot, getValue, and getSrcValue could reference this SDValue array.

This seems to be a problem with this code in
BasicAliasAnalysis::getModRefInfo(ImmutableCallSite CS, const Location &Loc)

  // If the pointer is to a locally allocated object that does not escape,
  // then the call can not mod/ref the pointer unless the call takes the
pointer
  // as an argument, and itself doesn't capture it.
  if (!isa<Constant>(Object) && CS.getInstruction() != Object &&
      isNonEscapingLocalObject(Object)) {


In this case the alloca for the SDValue array does escape through the call to
DAG.getNode so the isNonEscapingLocalObject returns false. But the CallSites in
question here are for getRoot, getValue, getSrcValue which it doesn't into.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list