<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 6, 2015, at 8:35 AM, Richard Diamond via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><br class="Apple-interchange-newline"><br class=""><div class="gmail_quote">On Tue, Nov 3, 2015 at 3:15 PM, Daniel Berlin<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:dberlin@dberlin.org" target="_blank" class="">dberlin@dberlin.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Tue, Nov 3, 2015 at 12:29 PM, Richard Diamond<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:wichard@vitalitystudios.com" target="_blank" class="">wichard@vitalitystudios.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Mon, Nov 2, 2015 at 9:16 PM, Daniel Berlin<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:dberlin@dberlin.org" target="_blank" class="">dberlin@dberlin.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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" class="">I'm very unclear and why you think a generic black box intrinsic will have any different performance impact ;-)<div class=""><br class=""></div><div class=""><br class=""></div><div class="">I'm also unclear on what the goal with this intrinsic is.</div><div class="">I understand the symptoms you are trying to solve - what exactly is the disease.</div><div class=""><br class=""></div><div class="">IE you say "</div><span class=""><br class=""><span style="font-size: 12.8px;" class="">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 class=""><span style="font-size: 12.8px;" class=""><br class=""></span></div></span><div class=""><span style="font-size: 12.8px;" class="">But why are you trying to achieve this goal?</span></div></div></blockquote><div class=""><br class=""></div></span><div class="">It's a cleaner design than current solutions (as far as I'm aware).</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Trying to make certain specific optimizations not work does not seem like a goal unto itself.</div><div class="">It's a thing you are doing to achieve something else, right?</div><div class="">(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 class=""><br class=""></div><div class="">What is the something else?</div><div class=""><br class=""></div><div class="">IE what is the problem that led you to consider this solution.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I apologize if I'm not being clear enough. This contrived example</div><div class="">```rust</div>#[bench]<br class="">fn bench_xor_1000_ints(b: &mut Bencher) {<br class=""> b.iter(|| {<br class=""> (0..1000).fold(0, |old, new| old ^ new);<br class=""> });<br class="">}<div class="">```</div><div class="">is completely optimized away. Granted, IRL production (ignoring the question of why this code was ever used in production in the first place) this optimization is desired, but here it leads to bogus measurements (ie 0ns per iteration). By using `test::black_box`, one would have</div><div class=""><br class=""></div><div class="">```rust</div><div class="">#[bench]<br class="">fn bench_xor_1000_ints(b: &mut Bencher) {<br class=""> b.iter(|| {</div><div class=""> let n = test::black_box(1000); // optional<br class=""> test::black_box((0..n).fold(0, |old, new| old ^ new));<br class=""> });<br class="">}<br class=""></div><div class="">```</div><div class="">and the microbenchmark wouldn't have bogos 0ns measurements anymore.</div><div class=""><br class=""></div><div class="">Now, as I stated in the proposal, `test::black_box` currently uses no-op inline asm to "read" from its argument in a way the optimizations can't see. Conceptually, this seems like something that should be modelled in LLVM's IR rather than by hacks higher up the IR food chain because the root problem is caused by LLVM's optimization passes (most of the time this code optimization is desired, just not here). Plus, it seems others have used other tricks to achieve similar effects (ie volatile), so why shouldn't there be something to model this behavior?</div></div></div></div></div></blockquote><div><br class=""></div><div>How would black_box be different from existing mechanism (inline asm, volatile, …)? </div><div>If the effect on the optimizer is not different then there is no reason to introduce a new intrinsic just for the sake of it. It has some cost: any optimization has to take this into account.</div><div><br class=""></div><div>On this topic, I think Chandler’s talk at CppCon seems relevant: <a href="https://www.youtube.com/watch?v=nXaxk27zwlk" class="">https://www.youtube.com/watch?v=nXaxk27zwlk</a></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </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" class=""><div class="gmail_extra"><div class="gmail_quote"><span class=""><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" class=""><div class="gmail_extra"><div class="gmail_quote"><span class=""><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" class=""><div class=""><span style="font-size: 12.8px;" class="">Benchmarks that can be const prop'd/etc away are often meaningless. </span></div></div></blockquote><div class=""> </div></span><div class="">A benchmark that's completely removed is even more meaningless, and the developer may not even know it's happening.<span class="Apple-converted-space"> </span></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Write good benchmarks?<br class=""><br class=""></div><div class="">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></div></blockquote><div class=""><br class=""></div><div class="">But users are also not testing how fast deterministic code which LLVM is completely removing can go. This intrinsic prevents LLVM from correctly thinking the code is deterministic (or that a value isn't used) so that measurements are (at the very least, the tiniest bit) meaningful.</div><div class=""><br class=""></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" class=""><div class="gmail_extra"><div class="gmail_quote"><span class=""><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" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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 class=""><br class=""></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" class=""><div class=""><span style="font-size: 12.8px;" class="">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 class=""><br class=""></div></span><div class="">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 class=""></div></div></blockquote></span><div class="">Speed bump? Hacky?</div><div class="">It's a completely normal test harness? </div><div class=""><br class=""></div><div class="">That's in fact, why llvm uses it as a test harness?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I mean I wouldn't write a harness or some other type of workaround for something like this: Rust doesn't seem to be the first to have encountered this issue, thus it is nonsensical to require every project using LLVM to have a separate harness or other workaround so they don't run into this issue. LLVM's own documentation suggests that adding an intrinsic is the best choice moving forward anyway: "Adding an intrinsic function is far easier than adding an instruction, and is transparent to optimization passes. If your added functionality can be expressed as a function call, an intrinsic function is the method of choice for LLVM extension." (from <a href="http://llvm.org/docs/ExtendingLLVM.html" class="">http://llvm.org/docs/ExtendingLLVM.html</a>). That sounds perfect to me.</div></div></div></div></div></blockquote><div><br class=""></div><div>The doc is about if you *need* to extend LLVM, then you should try with intrinsic instead of adding an instruction, it is the “need” part that is not clear here. The doc also states that an intrinsic is transparent to optimization passes, but it is not the case here since you want to prevent optimizations from happening (and you haven’t really specified how to decide what can an optimization do around this intrinsic, because if you don’t teach the optimizer about it, it will treat it as an external function call).</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div></div></body></html>