Closed huonw closed 10 years ago
I'm tagging this easy because I think it should be relatively easy to choose a few benchmarks from the list above to progressively fix. And mentor because I'm very happy to assist.
(Some of the benchmarks above may not be dead-code eliminated, but never the less are so small that the benchmarker doesn't have enough resolution to give meaningful results: changing it to something like for _ in range(0, 100) { ... }
would probably be appropriate.)
Could I take this issue?
Sure! (Don't feel required to do all of them at once.)
And I think everything except the collections::bitv
ones are legitimately fast (and so only the bitv
ones need fixing).
I think most of those are fixed by now. There are only a few left in bitv
where nothing is returned.
I'll prepare a pull request.
As #8261 describes one has to be careful with benchmarks to avoid them being optimised to remove the section of code that's actually of interest; many in tree benchmarks are not this careful.
12105 adds two ways to get around this:
Return a value from the closure
Call the noop
extra::test::black_box
function on some result of a calculation, e.g.In both cases, the value is unused, but LLVM can't be sure and so cannot remove optimise out the computation of the value.
The following are the benchmarks that took less than 10ns on the linux-64-opt buildbot (for the landing of #12105), and so are strong candidates for benchmarks that have been optimised to uselessness (there are probably others which aren't completely optimised to nothing, but still aren't benchmarking what they are purporting to):