[PATCH] D76248: Fix a bug in the inliner that causes subsequent double inlining
Hongtao Yu via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Mar 20 18:27:52 PDT 2020
hoyFB marked an inline comment as done.
hoyFB added inline comments.
================
Comment at: llvm/lib/Transforms/Utils/CloneFunction.cpp:361
+ // away later on.
+ if (!dyn_cast<CallBase>(NewInst) || !dyn_cast<CallBase>(V)) {
+ VMap[&*II] = V;
----------------
davidxl wrote:
> hoyFB wrote:
> > davidxl wrote:
> > > hoyFB wrote:
> > > > davidxl wrote:
> > > > > Is the first check needed (!dyn_cast<CallBase>(NewInst)) ?
> > > > It's needed when the inlined instruction is not a call but promoted to a call during the simplification. For example, some code on arm32/arm64 target could be promoted to a call or an intrinsic call. In this case we'd like to keep this simplification since the it will not cause double inlining given that the original instruction is not a call.
> > > Ok. Perhaps add a comment in the code?
> > Sounds good.
> It should be ok to do the simplification if V has no side effects .
A pure function call could have no side effect and may still cause double inlining. As long as V is a call, it could be shared by NewInst and another call site. Note that an irregular call graph processing order may not guarantee a pure function call like V be fully inlined before processing NewInst.
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