<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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><div>For what, exact, well defined goal?</div><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><br></div><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=""><div> </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"><div dir="ltr"><div><span style="font-size:12.8px">Benchmarks that can be const prop'd/etc away are often meaningless. </span></div></div></blockquote><div> </div></span><div>A benchmark that's completely removed is even more meaningless, and the developer may not even know it's happening. </div></div></div></div></blockquote><div><br></div><div>Write good benchmarks?<br><br></div><div>No, seriously, i mean, you want benchmarks that tests what users will see when the compiler works, not benchmarks that test what users see if the were to suddenly turn off parts of the optimizers ;)</div><div> </div><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"><div>I'm not saying this intrinsic will make all benchmarks meaningful (and I can't), I'm saying that it would be useful in Rust in ensuring that tests/benches aren't invalidated simply because a computation wasn't performed.</div><span class=""><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"><div dir="ltr"><div><span style="font-size:12.8px">Past that, if you want to ensure a particular optimization does a particular thing on a benchmark, ISTM it would be better to generate the IR, run opt (or build your own pass-by-pass harness), and then run "the passes you want on it" instead of "trying to stop certain passes from doing things to it".</span></div></div></blockquote><div><br></div></span><div>True, but why would you want to force that speed bump onto other developers? I'd argue that's more hacky than the inline asm.</div></div><br></div></div></blockquote><div>Speed bump? Hacky?</div><div>It's a completely normal test harness? </div><div><br></div><div>That's in fact, why llvm uses it as a test harness?</div><div><br></div><div>I guess i don't see why an intrinsic with not well defined semantics, used in weird ways to try to outsmart some but not all optimizations, is "less hacky" than a harness that says "hey, i want to see the effects of running mem2reg and code gen on this, without running constprop. So i'm just going to run mem2reg and codegen on this, and see the results!".</div><div>Because the former is just a way to try to magic the compiler, and the second expresses exactly what you want.</div><div><br></div></div><br></div></div>