SmallVector and SmallPtrSet allocations not power-of-two aligned

[Jean-Luc Duprat]

The best analogy I can think of is the \0 at the end of C string. Essentially the iterator now knows where the end of the data structure is, so it never steps beyond the end, and doesn't need to test for \0.
This makes the iterator a bit bigger, but makes the data structure more predictable in size (power-of-two-sized).

JL


On Mar 28, 2013, at 10:31 , Michael Ilseman <milseman at apple.com> wrote:

> 
> On Mar 27, 2013, at 5:44 PM, Sean Silva <silvas at purdue.edu> wrote:
> 
>> On Wed, Mar 27, 2013 at 5:42 PM, Jean-Luc Duprat <jduprat at apple.com> wrote:
>> These changes moved all the allocations identified above to proper power-of-two allocations.  These changes have no impact on performance, but will help pool memory allocations together if needed.
>> 
>> 
>> 
>> Have you dug into why the existing code is written so that the end iterator always points at valid memory? That is mentioned in multiple comments. It seems weird to do that, but I wouldn't change it without investigating why that was done in the first place.
>> 
> 
> The iterators have to step over tombstones/empty slots, so when ++ advances from the last set entry to a place that will compare equal with end(), it needed somewhere to land. By having an extra null entry that end() pointed to, that allowed it to stop and then compare equal. If not for that null entry, it wouldn't know it has left the data structure and might just march through memory arbitrarily. However, Jean-Luc's patch passes in end() to the iterator, so it can now behave correctly without needing the extra space.
> 
>> -- Sean Silva
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130328/46a03eaa/attachment.html>