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

Chandler Carruth chandlerc at gmail.com
Thu Dec 26 12:21:12 PST 2013


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:

"""
static const unsigned NumPointersPerGraveYard = ((1 << 16) / sizeof(void*))
- 1;
static unsigned GraveYardIndex = 0;
struct PointerGraveYard {
  void *DeadPtrs[NumPointersPerGraveYard];
  PointerGraveYard *PrevGraveYard;
} InitialGraveYard, *CurrentGraveYard = &InitialGraveYard;

void BuryPointer(void *p) {
  PointerGraveYard *G = CurrentGraveYard;
  if (GraveYardIndex >= NumPointersPerGraveYard) {
    CurrentGraveYard = new PointerGraveYard;
    CurrentGraveYard->PrevGraveYard = G;
    G = CurrentGraveYard;
    GraveYardIndex = 0;
  }

  G->DeadPtrs[GraveYardIndex++] = p;
}
"""

This seems likely to be way cheaper than the vector in all of the common
cases. I'm not really worried about the size of the static global either
because it would be mapped by the loader rather than taking up actual data
size in the binary.

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


More information about the cfe-commits mailing list