[PATCH] D76248: Fix a bug in the inliner that causes subsequent double inlining

David Li via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Mar 21 13:20:11 PDT 2020


davidxl added a comment.

Thanks for the explanation.

The inliner does bottom up inlining -- after inlining each site for a node, a worklist based TopDown Inlining is attempted (in breadth first order) -- i.e., the new callsites from the the cloned inline instance will be pushed to the queue. The candidate callsites must be originated from the callee, not a reference to a callsite in the caller due to simplification.  I think the better fix is at the queue update :

  if (!InlineInfo.InlinedCalls.empty()) {
     // Create a new inline history entry for this, so that we remember
     // that these new callsites came about due to inlining Callee.
     int NewHistoryID = InlineHistory.size();
     InlineHistory.push_back(std::make_pair(Callee, InlineHistoryID));
  
     for (Value *Ptr : InlineInfo.InlinedCalls)
       CallSites.push_back(std::make_pair(CallSite(Ptr), NewHistoryID));
   }

In otherwords, if the callsite is already in the queue, do not attempt to insert it into it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76248/new/

https://reviews.llvm.org/D76248





More information about the llvm-commits mailing list