[PATCH] D117356: InstructionCombining: avoid eliding mismatched alloc/free pairs
James Y Knight via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jan 19 13:49:18 PST 2022
jyknight added inline comments.
================
Comment at: llvm/lib/Transforms/InstCombine/InstructionCombining.cpp:2666
if (isFreeCall(I, &TLI)) {
+ if (getAllocationFamily(I, &TLI) != Family)
+ return false;
----------------
durin42 wrote:
> 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?
I think you can make that an `assert(FreeFamily)` instead (and `assert(Family)` at the top).
As you say, today it can't happen. And in the future, when we move this stuff into an attribute, I think it still shouldn't be able to happen -- in that future, part of the definition of "is this a free call" should be "has an allocator family attribute".
================
Comment at: llvm/test/Transforms/InstCombine/malloc-free-mismatched.ll:11-12
+ %2 = call noalias nonnull i8* @_Znam(i64 80) #0
+ %3 = bitcast i8* %2 to i32*
+ %4 = bitcast i32* %3 to i8*
+ call void @free(i8* %4)
----------------
These lines are irrelevant, remove (and rename %4 to %2 below).
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