[PATCH] D23636: [ADT] Allocate memory less often by increase inline storage

[Pete Cooper via llvm-commits]

> On Aug 18, 2016, at 3:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> I haven’t looked at profiles so I have no idea: do we have some good reasons to chose one size or another for an APIInt at each uses? 
> I mean will this be “statistic driven” (like in practice SCEV ends-up mostly with 65bits while constant ranges between 128 and 256 or something like that?

Here’s a patch I had from a while ago.  It generates a list of bit widths for constant ranges and counts of those bit widths.  You can choose which to sort by with a boolean in the code.



For values 64 bits and over, here’s the counts:

1921114, 64
36772, 65
1442, 66
3584, 67
4892, 68
3416, 69
2740, 70
74, 71
64683, 128
69144, 129
4594, 257

So most are 128 and 129.

Note, this is with around 8m APInt allocations coming from ConstantRange in total.  So the 200k or so we see above are just those which ultimately populate ConstantRanges.  The intermediate calculations in ConstantRange::[add, subtract, multiply] are what generate the other 8m or so.

Cheers,
Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160818/6acb93ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cr.diff
Type: application/octet-stream
Size: 2165 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160818/6acb93ef/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160818/6acb93ef/attachment-0001.html>