[PATCH] ignore --disable-free in clang when leak detection is enabled

[Chandler Carruth]

On Thu, Dec 26, 2013 at 10:47 PM, Kostya Serebryany <kcc at google.com> wrote:

> On Fri, Dec 27, 2013 at 12:21 AM, Chandler Carruth <chandlerc at gmail.com>wrote:
>
>>
>> On Thu, Dec 26, 2013 at 2:29 PM, Kostya Serebryany <kcc at google.com>wrote:
>>
>>> >> Isn't clang multithreaded? What about synchronization?
>>>   no (afaict)
>>>   If it ever becomes multithreaded, we can guard the push_backs by a
>>> mutex (will add a tiny bit of ugliness)
>>
>>
>> I think we could probably do a lot cheaper than a vector at least for the
>> common case -- we know we will *never* need to traverse this, and it will
>> probably be relatively small (at least, I hope...).
>>
>> I would compile some big single source files (single-source gcc, some
>> super big C++ code, etc.) with a hack that prints out how many free() calls
>> are being omitted via this flag. If the number is O(10000) I would probably
>> do something kinda horrible:
>>
> I expect it to be more like ~10 than ~10000. Remember we don't need to
> store all leaked heap objects there, only the roots.
>

Sure. But run the experiment. I just worry that we may end up with many
roots due to some pattern of free calls.


>
>> """
>> static const unsigned NumPointersPerGraveYard = ((1 << 16) /
>> sizeof(void*)) - 1;
>>
>
> But this is so much more code than a single vector!?
>

In terms of lines? Yes. But *way* less in terms of actual generated code I
would wager. And the whole point of --disable-free was that free() was
getting called frequently enough to slow things down. I don't want to add a
call to malloc() on that path! ;]

We could use a SmallVector, but that may end up being still more code, and
would be much harder to make the loader just zero initialize everything for
us....


> (And I like the naming!)
>

=]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131226/6b6b37a9/attachment.html>