[llvm] r214135 - IR: Optimize size of use-list order shuffle vectors

[Duncan P. N. Exon Smith]

> On 2014-Jul-29, at 10:19, Sean Silva <chisophugis at gmail.com> wrote:
> 
> First, I agree with Chandler about not worrying unless this is in the profile.
> 
> However, if this really does need to be optimized....
> 
> Crazy idea: would it be possible to store just a single int's worth of RNG seed for each use list?
> 
> A less crazy idea: a vector of indices is an extremely memory-inefficient way to store permutations. For example, there are 12! permutations of 12 elements, and 12! is less than 2^32. Similarly, there are 20! permutations of 20 elements and 20! < 2^64. Therefore your "small" case could theoretically be just a single `unsigned` from a storage perspective.
> A slightly memory-suboptimal but simple and cpu-friendly way to store the permutations in an integer would be to bit-pack the indices, using just as many bits for the indices as necessary. For example, suppose you were just allowed a single uint64. You could use the following arrangement to store permutations of up to 15 elements:
> Low 4 bits: number of elements (the "size")
> Each 4 bits after that: an index. Since we use 4 bits to store it, size() is at most 15, thus each index fits in 4 bits. 4 * 15 = 60, so that is just enough room for up to 15 elements.
> (there is actually room for quite a bit of out-of-band data; if size() < 15, then you have entire unused indices at the top and so you have 4*(15 - size()) bits available) 
> 

This makes a lot of sense to me.  I'm still trying to shake out some test
failures, but once I get to looking at memory overhead I think this is a good
direction.