google / benchmark / 2154

92%

push

travis-ci

<a href="https://github.com/google/benchmark/commit/<a class=hub.com/google/benchmark/commit/f92903cc5338daed898242f22015d8426c065770">f92903cc5<a href="https://github.com/google/benchmark/commit/f92903cc5338daed898242f22015d8426c065770">&quot;&gt;Iteration counts should be `uint64_t` globally. (#817)

This is a shameless rip-off of https://github.com/google/benchmark/pull/646
I did promise to look into why that proposed PR was producing
so much worse assembly, and so i finally did.

The reason is - that diff changes `size_t` (unsigned) to `int64_t` (signed).

There is this nice little `assert`:
https://github.com/google/benchmark/blob/</a><a class="double-link" href="https://github.com/google/benchmark/commit/<a class="double-link" href="https://github.com/google/benchmark/commit/7a1c37028359ca9d386d719a6ad527743cf1b753">7a1c37028</a>">7a1c37028</a><a href="https://github.com/google/benchmark/commit/f92903cc5338daed898242f22015d8426c065770">/include/benchmark/benchmark.h#L744
It ensures that we didn&#39;t magically decide to advance our iterator
when we should have finished benchmarking.

When `cached_` was unsigned, the `assert` was `cached_ UGT 0`.
But we only ever get to that `assert` if `cached_ NE 0`,
and naturally if `cached_` is not `0`, then it is bigger than `0`,
so the `assert` is tautological, and gets folded away.

But now that `cached_` became signed, the assert became `cached_ SGT 0`.
And we still only know that `cached_ NE 0`, so the assert can&#39;t be
optimized out, or at least it doesn&#39;t currently.

Regardless of whether or not that is a bug in itself,
that particular diff would have regressed the normal 64-bit systems,
by halving the maximal iteration space (since we go from unsigned counter
to signed one, of the same bit-width), which seems like a bug.
And just so it happens, fixing *this* bug, fixes the other bug.

This produces fully (bit-by-bit) identical state_assembly_test.s
The filecheck change is actually needed regardless of this patch,
else this test does not pass for me even without this diff.

22 of 22 new or added lines in 7 files covered. (100.0%)

1777 of 1937 relevant lines covered (91.74%)

5186830.02 hits per line