[llvm-bugs] [Bug 32363] New: Always inliner should not delete dead calls to readonly/readnone functions at -O0

[via llvm-bugs]

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

            Bug ID: 32363
           Summary: Always inliner should not delete dead calls to
                    readonly/readnone functions at -O0
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: llvm-bugs at lists.llvm.org

Consider this code:

void readonly(void) __attribute__((__const__));
void readonly(void) {}
void foo(void) { readonly(); }

This code built with 'clang -O0' ends up not calling 'readonly', which is bad
for debugging and dynamic instrumentation tools.

The inliner contains this logic:

      // If this call site is dead and it is to a readonly function, we should
      // just delete the call instead of trying to inline it, regardless of
      // size.  This happens because IPSCCP propagates the result out of the
      // call and then we're left with the dead call.
      if (isInstructionTriviallyDead(CS.getInstruction(), &TLI)) {
        DEBUG(dbgs() << "    -> Deleting dead call: " << *CS.getInstruction()
                     << "\n");
        // Update the call graph by deleting the edge from Callee to Caller.
        CG[Caller]->removeCallEdgeFor(CS);
        CS.getInstruction()->eraseFromParent();
        ++NumCallsDeleted;
      } else {
        // We can only inline direct calls to non-declarations.
        if (!Callee || Callee->isDeclaration())
          continue;

This logic should not be enabled at -O0.

-- 
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/20170321/8698befe/attachment.html>