<div dir="ltr"><div class="gmail_quote"><div>I'm super excited about all of the non-zeroing options here. I'd actually like to mention some more options that I want to see explored (in future work):</div><div><br></div><div>1) An enhancement to the pattern suggestion:</div><div><br></div><div>I'd like variables to be initialized to one of N patterns (using the very nice pattern scheme you outline). The N patterns need to *include* zero. The selection of the pattern needs to be very hard to rely on. My suggestion would be to rotate between a shuffled list of patterns for each initialization in the function (even better to do this in LLVM after inlining etc). And shuffle the list of patterns using various inputs: the version of the compiler, some user-provided input (random seed?), and the (mangled) name of the function.</div><div><br></div><div>The reason I want this is that I think even all 0xAA can be relied upon inadvertently by programmers. As an example: it will reliably initialize booleans to `true`.</div><div><br></div><div>I would like to see something like this as the default instead of the all-0xAA option.</div><div><br></div><div>2) An extension to this pattern (maybe call it "dynamic-pattern") would be to read the pattern (or some of the N patterns) from a buffer initialized at program start time.</div><div><br></div><div>While #2 may imply some overhead, it may be lower than expected -- copying memory is in some weird cases faster than materializing patterns and then setting memory. And it may have some advantages.</div><div><br></div><div><br></div><div>All of that said:</div><div dir="ltr"><br></div><div dir="ltr">On Thu, Nov 15, 2018 at 5:06 PM Tim Northover via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 16 Nov 2018 at 00:42, JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank">jfbastien@apple.com</a>> wrote:<br>
> Sounds fair?<br>
<br>
No, it doesn't. It's putting the entire burden on backend optimizers,<br>
with the goal of removing zero-init at some unspecified future date.<br>
It's nothing even remotelty approaching a compromise.<br>
<br>
The fragmentation issues need to be considered up front.<br></blockquote><div><br></div><div>FWIW, I agree about the zero case. I'm deeply concerned about fragmentation here.</div><div><br></div><div>But I *also* really want to be able to get the data and measurements needed to address performance problems with non-zero initialization.</div><div><br></div><div>I would love to see a way to get the zero initialization behavior for performance testing, but *not* expose this as a supported flag to users. I can imagine many ways to do that. Tim, would that address your concerns? In that way, we could actually refuse to support the zero behavior long term by making it much more apparent that it is only intended to gather data.</div></div></div>