Re: C++ function that the optimizer won't eliminate

2017-11-09 Thread Henri Sivonen
On Wed, Oct 11, 2017 at 11:54 PM, Gabriele Svelto wrote: > On 09/10/2017 13:47, Henri Sivonen wrote: >> I omitted volatile, because the GCC manual said it has no effect on >> basic asm. However, it turns out it still has an effect on extended >> asm, which is what this is. Oops. > > Yes, volatile

Re: C++ function that the optimizer won't eliminate

2017-10-11 Thread Gabriele Svelto
On 09/10/2017 13:47, Henri Sivonen wrote: > I omitted volatile, because the GCC manual said it has no effect on > basic asm. However, it turns out it still has an effect on extended > asm, which is what this is. Oops. Yes, volatile implies the statement has side effects and so it cannot be moved a

Re: C++ function that the optimizer won't eliminate

2017-10-09 Thread David Major
> On Fri, Oct 6, 2017 at 5:41 PM, David Major wrote: > > I bet Google Benchmark will have what you want. > > > > As a first guess, maybe this? > > https://github.com/google/benchmark/blob/master/include/ > benchmark/benchmark.h#L297 > > Thank you. I guess it's the best to import that into the tree

Re: C++ function that the optimizer won't eliminate

2017-10-09 Thread Henri Sivonen
On Fri, Oct 6, 2017 at 4:16 PM, Gabriele Svelto wrote: > IIUC what you are looking for is the '+' constraint which implies the > parameter is both read and written in the asm statement, e.g.: Thanks. On Fri, Oct 6, 2017 at 4:01 PM, Nathan Froyd wrote: > Can you provide a slightly larger example

Re: C++ function that the optimizer won't eliminate

2017-10-06 Thread Botond Ballo
Not immediately useful to us, but there is a C++ standards proposal in the works for a standard library function along these lines: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0412r0.html Cheers, Botond ___ dev-platform mailing list dev-pla

Re: C++ function that the optimizer won't eliminate

2017-10-06 Thread David Major
I bet Google Benchmark will have what you want. As a first guess, maybe this? https://github.com/google/benchmark/blob/master/include/benchmark/benchmark.h#L297 (And if godbolt says they are wrong, please send them a PR :)) On Fri, Oct 6, 2017 at 9:16 AM, Gabriele Svelto wrote: > On 06/10/201

Re: C++ function that the optimizer won't eliminate

2017-10-06 Thread Gabriele Svelto
On 06/10/2017 11:00, Henri Sivonen wrote: > Do we already have a C++ analog of Rust's test::black_box() function? > I.e. a function that just passes through a value but taints it in such > a way that the optimizer can't figure out that there are no side > effects. (For the purpose of ensuring that

Re: C++ function that the optimizer won't eliminate

2017-10-06 Thread Nathan Froyd
On Fri, Oct 6, 2017 at 5:00 AM, Henri Sivonen wrote: > Do we already have a C++ analog of Rust's test::black_box() function? We do not. > Specifically, this isn't the answer for GCC: > void* black_box(void* foo) { > asm ("":"=r" (foo): "r" (foo):"memory"); > return foo; > } Can you provide

Re: C++ function that the optimizer won't eliminate

2017-10-06 Thread Boris Zbarsky
On 10/6/17 5:00 AM, Henri Sivonen wrote: If we don't have one, how should one be written so that it works in GCC, clang and MSVC? Are you OK with it being restricted to a single thread? If so, would something like this work? mutable void* taint; void* black_box(void* foo) { taint =

C++ function that the optimizer won't eliminate

2017-10-06 Thread Henri Sivonen
Do we already have a C++ analog of Rust's test::black_box() function? I.e. a function that just passes through a value but taints it in such a way that the optimizer can't figure out that there are no side effects. (For the purpose of ensuring that the compiler can't eliminate computation that's be