<div dir="ltr"><div class="gmail_extra">One thing that volatile doesn't do is escape results that have been written to memory.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The proposed blackbox intrinsic is modeled as reading and writing any pointed to memory, which is useful.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I also think blackbox will be a lot easier for people to use than empty volatile inline asm and volatile loads and stores. That alone seems worth something. :)</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 6:04 PM, Daniel Berlin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
</div></div>I think the fundamental thing you're missing is that benchmarks are an<br>
exercise in if/then:<br></blockquote><div><br></div></span><div>I don't believe i'm actually missing anything.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
*If* a user exercises this API, *then* how well would it perform?</blockquote><div><br></div></span><div>In this case, he exercised the API, and the compiler optimized it away.</div><div>If he wants to test whether the API, exercised in some other way, will be optimized, he should test that.</div><div><br>Your argument that this can't be tested is *almost always* false.  It's true sometimes, but that's *actually pretty rare*.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Of course, in the case of a user, the data could come from anywhere, and<br>
go anywhere - the terminal, a network socket, whatever.<br>
<br>
However, in a benchmark, all the data comes from (and goes) to places the<br>
compiler and see.<br></blockquote><div><br></div></span><div>This is not necessarily true, but as I said, the way around this is to use volatile.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thus, it's necessary to make the compiler _pretend_ the data came from<br>
and goes to a "black box", in order for the benchmarks to even *remotely*<br>
resemble what they're meant to test.<br></blockquote><div><br></div><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"><br>
This is actually distinct from #1, #2, _and_ #3 above - quite simply,<br>
what is needed is a way to simulate a "real usage" scenario without<br>
actually contacting the external world.<br>
<div><div><br></div></div></blockquote><div><br></div></span><div>No. It is not distinct in any way, and you haven't shown why it is.</div><div>It is exactly  "i want this operation to happen exactly X times despite whether the compiler thinks it is necessary or can be removed"</div><div><br></div><div>That is volatile.</div><div><br></div></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>