<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div>This makes the iterator a bit bigger, but makes the data structure more predictable in size (power-of-two-sized).</div><div><br></div><div>JL</div><div><br><div><br><div><div>On Mar 28, 2013, at 10:31 , Michael Ilseman <<a href="mailto:milseman@apple.com">milseman@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 27, 2013, at 5:44 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Wed, Mar 27, 2013 at 5:42 PM, Jean-Luc Duprat <span dir="ltr"><<a href="mailto:jduprat@apple.com" target="_blank">jduprat@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br><br></blockquote></div>
</div><div class="gmail_extra" style=""><br></div><div class="gmail_extra" style=""><br></div><div class="gmail_extra" style="">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.</div>
<div class="gmail_extra" style=""><br></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra" style="">-- Sean Silva</div></div>
_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br></blockquote></div><br></div></blockquote></div><br></div></div></body></html>