[LLVMbugs] [Bug 12474] New: In-memory metadata representation is bloated.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=12474

             Bug #: 12474
           Summary: In-memory metadata representation is bloated.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Sadly, that's not easy to fix. All numbers below are for x86_64.

MDNodes (56 bytes + operands) use coallocated space to store their operands.
Each of the operands (MDNodeOperand, 40 bytes) is a CallbackVH with the
following layout.

   0 | class llvm::MDNodeOperand
   0 |   class llvm::CallbackVH (primary base)
   0 |     (CallbackVH vtable pointer)
   8 |     class llvm::ValueHandleBase (base)
   8 |       class llvm::PointerIntPair<ValueHandleBase **, 2> PrevPair
  16 |       class llvm::ValueHandleBase * Next
  24 |       class llvm::Value * VP
  32 |   class llvm::MDNode * Parent

There is some redundancy here. We store the same vptr and Parent ptr on every
operand of a MDNode, and some debug MDNodes tend to have a lot of operands
(16+). When uniquing MDNodes we extract the value ptr from every operand, that
has obviously bad implications for the cpu cache.

Eliminating at least the vptr (8 bytes) would be nice, but it looks like
ValueHandleBase has no more bits :(


Another offender is MDString (56 bytes). They're uniqued in a
StringMap<MDString *> but the objects itself are allocated on the side. It
should be possible to move the MDString into the StringMap, saving a malloc.
Furthermore MDString objects contain a StringRef pointing back to the string
stored in the StringMap. This is redundant as the string data will always be at
a constant offset from the MDString if it is allocated in the StringMap. I
don't see a non-hackish way to exploit this though.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.