search for: black_box

Hey all, I'd like to propose a new intrinsic for use in preventing optimizations from deleting IR due to constant propagation, dead code elimination, etc. # Background/Motivation In Rust we have a crate called `test` which provides a function, `black_box`, which is designed to be a no-op function that prevents constprop, die, etc from interfering with tests/benchmarks but otherwise doesn't negatively affect resulting machine code quality. `test` currently implements this function by using inline asm, which marks a pointer to the argument as use...

...0).fold(0, |old, new| old ^ new); }); } ``` 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 ```rust #[bench] fn bench_xor_1000_ints(b: &mut Bencher) { b.iter(|| { let n = test::black_box(1000); // optional test::black_box((0..n).fold(0, |old, new| old ^ new)); }); } ``` and the microbenchmark wouldn't have bogos 0ns measurements anymore....

On Mon, Nov 2, 2015 at 9:16 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > I'm very unclear and why you think a generic black box intrinsic will have > any different performance impact ;-) > > > I'm also unclear on what the goal with this intrinsic is. > I understand the symptoms you are trying to solve - what exactly is the > disease. > > IE you say

...ime than clang (-O2). The run-time performance is the same. gcc -O2 compile time is even faster (10X) but is significantly worse in run-time performance than clang -O2. One thing I noticed was that if I converted the switch from: switch (x) { ... } to: extern int black_box(int); // opaque identity function switch (black_box(x)) { ... } the compile time improves significantly. I am using clang version 3.3. I also noticed that there have been similar reports about GVN performance in the past. See this link: http://lists.cs.uiuc.edu/pipermail/llvmbugs/20...

The common use case I've seen for a black box like construct is when writing microbenchmarks. In particular, you're generally looking for a way to "sink" the result of a computation without having that sink outweigh the cost of the thing you're trying to measure. Common alternate approaches are to use a volatile store (so that it can't be eliminated or sunk out of

On Wed, Nov 11, 2015 at 07:14:28PM -0800, Sean Silva via llvm-dev wrote: > Can you show a real benchmark that users have tried to write where the call > overhead of actually using an external function call is measurable? This is the wrong question. The correct question is: What useful benchmark cannot trivally factor out the overhead of the external function call. Yes, if you do

...piecewise on the register native component types of the type if need be. > And how is rustc to know exactly which are the register sized or smaller > types? rustc mostly leaves such knowledge to LLVM. > > Good idea, but the needed logistics would make it ugly. > > - Mark test::black_box as noinline > > Also not ideal because of the mandatory function call overhead. > > - External function > > Impossible for Rust; generics are monomorphised into the crate in which it > is used (ie the resulting function in IR won’t ever be external to the > module using i...

Hi all, i'm using wine under ArchLinux x86_64, i tested some versions (include the last, wine-1.4-rc5) and my problem is ever the same, i open any game and crash at start with this screen http://i.imgur.com/gpaYo.jpg The log when the app crash Code: err:menubuilder:init_xdg error looking up the desktop directory fixme:d3d_caps:wined3d_guess_card No card selector available for GL vendor 0x4