[PATCH] D69591: Devirtualize a call on alloca without waiting for post inline cleanup and next DevirtSCCRepeatedPass iteration.

Hiroshi Yamauchi via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 19 15:37:12 PST 2019


yamauchi marked 2 inline comments as done.
yamauchi added inline comments.


================
Comment at: llvm/lib/Analysis/Loads.cpp:458
+      // alias analysis.
+      APInt LoadOffset(DL.getTypeSizeInBits(Ptr->getType()), 0);
+      APInt StoreOffset(DL.getTypeSizeInBits(
----------------
davidxl wrote:
> what is the change intended for? If it fixes some bugs, it should be split out.
If AA were available (not null), this code wouldn't be necessary as it can handle the general AA. However, in the new code in Inliner.cpp, we currently call this function (FindAvailableLoadedValue) with a null AA as AA appears to be unavailable in the inliner. I may be confused but I am under the impression that AA is too expensive to recompute or update during inlining (inlining involves relatively a large amount of transformation of code) or that AA may be stateless in reality, but its interface doesn't give that guarantee and not to be relied upon. This code here attempts to handle a simple/special case of AA for stores/loads with different constant offsets off the same base pointer in the absence of AA, in the spirit of the code just above (lines 450-453). This is important for the targeted missed inlining case because it's about a virtual call on a stacked allocated object where it's quite likely some other fields of the object may be stored into besides the vtable pointer in the constructor. Without this code or AA, this function wouldn't go far enough through loads/stores to reach the vtable pointer store in the constructor and the target function pointer in it, and it wouldn't work.


================
Comment at: llvm/lib/Transforms/IPO/Inliner.cpp:897
+static void tryPromoteCall(CallSite &CS) {
+  assert(!CS.getCalledFunction());
+  Module *M = CS.getCaller()->getParent();
----------------
davidxl wrote:
> The pattern recognition part can be extracted as a utility/helper function and put int perhaps IndirectCallPromotionAnalysis.h|cpp file.
Will try.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69591





More information about the llvm-commits mailing list