<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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 class=""><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><div>It's a cleaner design than current solutions (as far as I'm aware).</div><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><div>A benchmark that's completely removed is even more meaningless, and the developer may not even know it's happening. 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><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><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>