<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 6, 2015 at 8:35 AM, Richard Diamond <span dir="ltr"><<a href="mailto:wichard@vitalitystudios.com" target="_blank">wichard@vitalitystudios.com</a>></span> wrote:<br><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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Nov 3, 2015 at 3:15 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Nov 3, 2015 at 12:29 PM, Richard Diamond <span dir="ltr"><<a href="mailto:wichard@vitalitystudios.com" target="_blank">wichard@vitalitystudios.com</a>></span> wrote:<br><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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Nov 2, 2015 at 9:16 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><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"><div dir="ltr">I'm very unclear and why you think a generic black box intrinsic will have any different performance impact ;-)<div><br></div><div><br></div><div>I'm also unclear on what the goal with this intrinsic is.</div><div>I understand the symptoms you are trying to solve - what exactly is the disease.</div><div><br></div><div>IE you say "</div><span><br><span style="font-size:12.8px">I'd like to propose a new intrinsic for use in preventing optimizations from deleting IR due to constant propagation, dead code elimination, etc."</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">But why are you trying to achieve this goal?</span></div></div></blockquote><div><br></div></span><div>It's a cleaner design than current solutions (as far as I'm aware).</div></div></div></div></blockquote><div><br></div></span><div>For what, exact, well defined goal? </div></div></div></div></blockquote><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Trying to make certain specific optimizations not work does not seem like a goal unto itself.</div><div>It's a thing you are doing to achieve something else, right?</div><div>(Because if not, it has a very well defined and well supported solutions - set up a pass manager that runs the passes you want)</div><div><br></div><div>What is the something else?</div><div><br></div><div>IE what is the problem that led you to consider this solution.</div></div></div></div></blockquote><div><br></div></span><div>I apologize if I'm not being clear enough. This contrived example</div><div>```rust</div>#[bench]<br>fn bench_xor_1000_ints(b: &mut Bencher) {<br>    b.iter(|| {<br>        (0..1000).fold(0, |old, new| old ^ new);<br>    });<br>}<div>```</div><div>is completely optimized away.</div></div></div></div></blockquote><div><br></div><div><br>Great!</div><div><br></div><div>You should then test that this happens, and additionally write a test that can't be optimized away, since the above is apparently not a useful microbenchmark for anything but the compiler ;-)</div><div><br></div><div>Seriously though, there are basically three cases (with a bit of handwaving)<br><br></div><div>1. You want to test that the compiler optimizes something in a certain way.  The above example, without anything else, you actually want to test that the compiler optimizes this away completely.</div><div>This doesn't require anything except using something like FIleCheck and producing IR at the end of Rust's optimization pipeline.</div><div><br></div><div>2. You want to make the above code into a benchmark, and ensure the compiler is required to keep the number and relative order of certain operations.</div><div>Use volatile for this.<br></div><div><br></div><div>Volatile is not what you seem to think it is, or may think about it in terms of what people use it for in C/C++.</div><div>volatile in llvm has a well defined meaning:<br><a href="http://llvm.org/docs/LangRef.html#volatile-memory-accesses">http://llvm.org/docs/LangRef.html#volatile-memory-accesses</a><br></div><div><br></div><div>3. You want to get the compiler to only do certain optimizations to your code.</div><div><br></div><div>Yes, you have to either write a test harness (even if that test harness is "your normal compiler, with certain flags passed"), or use ours, for that ;-)</div><div><br></div><div><br></div><div>It seems like you want #2, so you should use volatile.</div><div><br></div><div>But don't conflate #2 and #3.</div><div><br></div><div>As said:<br>If you want the compiler to only do certain things to your code, you should tell it to only do those things by giving it a pass pipeline that only does those things.  Nothing else is going to solve this problem well.</div><div><br></div><div>If you want the compiler to do every optimization it knows to your code, but want it to maintain the number and relative order of certain operations, that's volatile.</div><div><br></div></div></div></div>