[PATCH] D156618: [IR] Fix a memory leak if Function::dropAllReferences() is followed by setHungoffOperand

Liqiang Tao via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 4 23:25:04 PDT 2023


taolq added a comment.

In D156618#4637306 <https://reviews.llvm.org/D156618#4637306>, @dexonsmith wrote:

> In D156618#4636483 <https://reviews.llvm.org/D156618#4636483>, @taolq wrote:
>
>> In D156618#4632192 <https://reviews.llvm.org/D156618#4632192>, @dexonsmith wrote:
>>
>>> In D156618#4632179 <https://reviews.llvm.org/D156618#4632179>, @dexonsmith wrote:
>>>
>>>> Seems unfortunate to add calls to `ConstantPointerNull::get()` when all of the callers are about to call `delete`.
>>>>
>>>> Can we instead somehow enforce that `delete` is always called right after? Perhaps add an assertion that this is so?
>>>
>>> Or, looking back at the motivation (calling `deleteBody()`), can we have two entry points?
>>>
>>> - One prepares for deletion (99% of callers), skips `CPN::get()`
>>> - One makes it a prototype (deleteBody), calls `CPN::get()`
>>
>> Thanks for the comment. I think it is a little redundant. Since we already has dector to release the memory, another entry points seems redundant.
>> So I'd like to reserve the only prototype version.
>
> What is "dector"?

I made a typo. I mean dtor, destructor.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156618



More information about the llvm-commits mailing list