[PATCH] D18586: Allow DeadStoreElimination to track combinations of partial later wrties

Chandler Carruth via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 31 22:31:55 PDT 2016


chandlerc added a comment.

In http://reviews.llvm.org/D18586#389096, @hfinkel wrote:

> - Original Message -----
>
> > From: "Chandler Carruth" <chandlerc at gmail.com>
>
> >  The major downside I see is that it doesn't scale gracefully to
>
> >  *large* memory regions like a memset might hit...
>
>
> What if I used a SparseBitVector. Perhaps that's the best of both worlds?


I think not sadly, at least if I'm thinking about this right...

SparseBitVector makes setting a large range or testing if all are set significantly more expensive when there are many bits than a normal BitVector, but with both the cost is linear in the number of bits set where as with IntervalMap it is constant in the size of the interval, and a very nice logarithmic factor in the number of disjoint intervals.

In the worst case for the IntervalMap, we would do N inserts for N stores, and if all were disjoint, the cost would be log(N), so total would be N*log(N).

In the worst case for either BitVector, we would do N inserts of the same M - 1 bits for an M byte size object which would be N * M. So when M becomes large, this will become quite slow. This isn't really helped by it being sparse either as it is sparse in the zero bits, not the set bits.


http://reviews.llvm.org/D18586





More information about the llvm-commits mailing list