<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 27, 2020 at 8:45 PM Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>Sorry for falling off the map on this thread:</div><div><br></div>On Nov 17, 2020, at 1:42 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<div><blockquote type="cite"><div><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Thoughts/suggestions:<br>- Adding the default seems very reasonable to me, and I think that 64 bytes is a good default.  I think you should change the behavior so that SmallVector<LargeThing> defaults to a single inline element instead of zero though.  Perhaps generate a static_assert when it is crazy large.<br></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Out of curiosity: Why a single rather than zero?</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"></div></div></blockquote></div><br><div>My rationale for this is basically that SmallVector is typically used for the case when you want to avoid an out-of-line allocation for a small number of elements, this was the reason it was created.  While there is some performance benefits of SmallVector<T,0> over std::vector<> they are almost trivial.  I don’t see why we’d recommend SmallVector<T,0> over vector to get those. </div></div></blockquote><div><br>Fair - though we do recommend it: <a href="https://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h">https://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h</a><br>"<span style="color:rgb(0,0,0);font-family:"Lucida Grande","Lucida Sans Unicode",Geneva,Verdana,sans-serif;font-size:14px">SmallVector has grown a few other minor advantages over std::vector, causing </span><code class="gmail-docutils gmail-literal gmail-notranslate" style="font-family:Consolas,"Deja Vu Sans Mono","Bitstream Vera Sans Mono",monospace;font-size:0.95em;color:rgb(0,0,0)"><span class="gmail-pre" style="hyphens: none;">SmallVector<Type,</span> <span class="gmail-pre" style="hyphens: none;">0></span></code><span style="color:rgb(0,0,0);font-family:"Lucida Grande","Lucida Sans Unicode",Geneva,Verdana,sans-serif;font-size:14px"> to be preferred over </span><code class="gmail-docutils gmail-literal gmail-notranslate" style="font-family:Consolas,"Deja Vu Sans Mono","Bitstream Vera Sans Mono",monospace;font-size:0.95em;color:rgb(0,0,0)"><span class="gmail-pre" style="hyphens: none;">std::vector<Type></span></code><span style="color:rgb(0,0,0);font-family:"Lucida Grande","Lucida Sans Unicode",Geneva,Verdana,sans-serif;font-size:14px">."<br></span><br>Happy if that decision's being revisited.<br><br>But even then, there might be some benefit (in addition to the other benefits mentioned in the Programmers Manual - though I'm not fully on board with the "never use std::vector" idea... undecided there) to not having to churn the name of a type (& possibly the subsequent uses of SmallVectorImpl, etc) when a struct changes size tipping it over the limit for SmallVector?<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div> If we were in favor of banning std::vector, then I think the reason would be for consistency across the codebase and to get things like pop_back_val().</div><div><br></div><div>One other way to handle this is to make there be a static_assert for the case where the size is inferred to zero.</div><div><br></div><div><blockquote type="cite"><div>On Nov 25, 2020, at 10:55 PM, Michael Kruse via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><div>Am Mi., 25. Nov. 2020 um 17:52 Uhr schrieb David Blaikie via llvm-dev<br><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>:<br><blockquote type="cite">I'm still not sure why "at least 1" is an important goal. I'd be<br>curious to hear from Chris/others why that's especially valuable.<br></blockquote><br>If N is 0, then it's not a small-size optimized vector, in contrast to<br>what the name implies.<br></div></blockquote></div><div><div><br></div></div><div>Right, exactly.</div><div><br></div><div><blockquote type="cite"><div>On Nov 17, 2020, at 2:15 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>> wrote:</div><div><div style="overflow-wrap: break-word;"><div><div>I'd be a bit concerned about this for two reasons:</div><div><br></div><div>- Adding a large inlined element by-default may reinforce one of the problems with SmallVector, that people accidentally put big vectors in places that shouldn't have them. If we're going to make accidentally large inlined vectors more ergonomic, I think we ought to make 0-element versions more ergonomic too.</div></div></div></div></blockquote><div><br></div><div>I don’t understand your rationale here: the issue in question comes from when T is large not when the count is large (since we’re talking about the inferred count case).</div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word;"><div><div>- The `static_assert` is going to fail differently on different platforms, since `T`'s size will tend to be platform-dependent for large `T`. I'm not sure it'll be predictable enough.</div></div></div></div></blockquote></div><div><div><div style="overflow-wrap: break-word;"><div><div><br></div><div>I agree this is a problem.  One way to do that is to make the assert only trip on sizeof(void*)==8 hosts or something to make it more “incomplete but (more) stable”.</div><div><br></div></div></div></div></div><div>-Chris</div></div></blockquote></div></div>