[PATCH] D109917: [InstCombine] Improve TryToSink for side-effecting calls that would be trivially dead
Philip Reames via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 28 09:57:26 PDT 2021
reames added inline comments.
================
Comment at: llvm/lib/Transforms/InstCombine/InstructionCombining.cpp:3718
+ (isStackStateMod && Scan->isFunctionStackStateModifying()))
+ return false;
+ }
----------------
reames wrote:
> Hm, I am not sure here, but I think you should check for potential reads here as well.
>
> My reasoning is as follows. While the instruction we're moving might be trivially dead if there are no users, it may *not* be trivially dead if there are users. There may be some externally arranged invariant that (say) the result is stored with a volatile variable *if-and-only-if* the call actually has a side effect.
>
> As an example, consider the following:
> a = malloc()
> stat = malloc_library_counter()
> if (c)
> free(a)
>
> Basically, is it legal to sink the malloc in this case? I legitimately don't know what the right answer is here.
>
> Another example might be:
> a = malloc()
> stat = malloc_library_counter()
> if (c)
> (volatile i8*)g = a;
>
JFYI, my potential cases just described are definitely disallowed by the function comment in the header which describes trivial-deadness. Unfortunately, so is malloc. As such, that comment is definitely wrong, and needs updated. :)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D109917/new/
https://reviews.llvm.org/D109917
More information about the llvm-commits
mailing list