[llvm-bugs] [Bug 26921] New: Reduce memory consumption of LazyValueInfo

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26921

            Bug ID: 26921
           Summary: Reduce memory consumption of LazyValueInfo
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: listmail at philipreames.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Currently, LVI stores it's cache in a very memory inefficient way.  We can
probably get something on the order of a 2x reduction in memory usage with some
fairly minor changes.

The LVILatticeVal consists of the following fields:
  LatticeValueTy Tag;
  Constant *Val;
  ConstantRange Range;

Tag is a 32 bit value (default enum size), where only three bits are used.

ConstantRange is a pair of APInts, each of which are a minimum of 96 bits, but
probably actually 128 bits each when accounting for padding.  Given the
bitwidth of each pair is the same, this is a particularly inefficient use of
space.  

Val and Range are also used exclusively of each other (based on tag).

One idea would be to allocate the ConstantRange's into a separate uniquing set,
then replace the ConstantRange with a ConstantRange* to the uniqued element. 
This would allow us to use a tagged pointer representation to reduce the entire
LVILatticeVal structure to 64 bits.  Even assuming that none of our
ConstantRanges ended up being common (unlikely), that would still be a
reduction of 64 bits per entry.  

We could also factor our the bitwidth storage from APInt and common the storage
for the two APInt's within a ConstantRange.  This would give us a 64 bit
reduction in the size of each ConstantRange (32 bit unsigned value + 1 x
padding).

Another thing to investigate is the representation of the ValueCache as an
std::map.  Using something like a DenseMap<std::pair<LVIValueHandle,
AssertingVH<BasicBlock>>, LVILatticeVal> might be a better choice.

There are probably other ways to slice this problem as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160312/ba4c7d8e/attachment.html>