[PATCH] D117356: InstructionCombining: avoid eliding mismatched alloc/free pairs
Augie Fackler via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 18 16:17:54 PST 2022
durin42 marked 4 inline comments as done.
durin42 added a comment.
I'll poke the enum later today or first thing tomorrow. I got stuck in a tarpit of being sad about the `arc` command line tool today.
================
Comment at: llvm/lib/Transforms/InstCombine/InstructionCombining.cpp:2666
if (isFreeCall(I, &TLI)) {
+ if (getAllocationFamily(I, &TLI) != Family)
+ return false;
----------------
reames wrote:
> With the semantics you're proposing, having two unannotated alloc/free be removed seems inconsistent.
>
> Also, use compound if clause.
I think we can't fuse the conditions, because if we see a `free()` call on a `new`ed pointer we should give up on the instruction combining, not allow it to possibly proceed on other methods, right?
Agreed on the unannotated functions meshing being inconsistent. Today that can't happen, but I guess when we move this to supporting attributes it could. Should the logic be something more like:
if (isFreeCall(...)) {
auto FreeFamily = getAllocationFamily(...);
if (FreeFamily == None || FreeFamily != Family)
return false;
...
}
or is there more to it than that that I'm missing?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D117356/new/
https://reviews.llvm.org/D117356
More information about the llvm-commits
mailing list