@noopt macro for avoiding optimizations

[KristofferC]

For e.g. benchmarking purposes it would be convenient to have a @noopt macro or something that would instruct the compiler not to optimize something. For example, the google benchmark suite has the following code

// The DoNotOptimize(...) function can be used to prevent a value or
// expression from being optimized away by the compiler. This function is
// intended to add little to no overhead.
// See: https://youtu.be/nXaxk27zwlk?t=2441
#ifndef BENCHMARK_HAS_NO_INLINE_ASSEMBLY
template <class Tp>
inline BENCHMARK_ALWAYS_INLINE void DoNotOptimize(Tp const& value) {
  asm volatile("" : : "r,m"(value) : "memory");
}

https://github.com/google/benchmark/blob/d8c0f27448dfad95b94285e612bba1f7c55c9dd0/include/benchmark/benchmark.h#L304-L347

(also see https://www.youtube.com/watch?v=nXaxk27zwlk&feature=youtu.be&t=2441 as the comment links to)

It would be useful to have something similar in Julia.

[yuyichao]

@noinline?

[KristofferC]

Is that really enough?

julia> @noinline f(x) = sin(x)*exp(x)
f (generic function with 1 method)

julia> g() = (x = 2.0; for i in 1:10^5; f(x); end)
g (generic function with 2 methods)

julia> @time g()
  0.000004 seconds (4 allocations: 160 bytes)

I want the compiler to assume that f (or just reading x) has an arbitrary side effect so it better actually run the code in there.

[vchuravy]

My favourite line is:

  │         (Main.f)(x::Const(2.0, false))::Const(6.71885, false)                                                                                                                               │

But there are two separate concerns here.
The first is that the Julia optimizer is becoming scarily clever (when did we start constant-propping through exp and sin...),
The second one is that you want clobber and escape from JuliaCI/BenchmarkTools.jl#92 if you don't want LLVM to pull the rug out under your feet.

[JeffreySarnoff]

We do need @noopt in addition to @noinline unless @noinline is going to do things in addition to precluding the inlining of some code (it seems that it does some of that already .. not sure). Anyway it would be best for @noinline to suppress inlining and @noopt to have at least two flavors. For benchmarking, we want @noopt to let the code we have written be instrumented and analyzed without introducing possibly helpful transformations that take the process away from our focus.

The other flavor, or another modifier [what which one is theoretically best] that captures the notion of "Please do what you can to take this stellar code to the next level of stellar without monkeying about with this line/ these few lines / this little section; that's the only way to preserve the design semantics."

[KristofferC]

Should probably be put inside a benchmarking package.

[JeffreySarnoff]

I had wanted this for general use with writing parts of numerical code that must not be reorganized or optimized away by the compiler. It would be problematic to have to depend upon a benchmarking package for this.

[KristofferC]

I had wanted this for general use with writing parts of numerical code that must not be reorganized or optimized away by the compiler.

Could you give an example? An optimization is not supposed to be observable.