GCov space optimization

[Andrew Stubbs]

Hi all,

Question: Would it be acceptable to introduce a new "counter" variety, 
together with options and UI support, that simply records a "visited" state?

Have there been any previous efforts in this space that I've missed?


I'm currently looking at the feasibility of reducing the memory 
footprint of coverage testing.  I don't have any figures or testcases 
yet, but the customer states that coverage testing works, except that 
the memory usage can be a problem on their devices, so I'm exploring 
what options we have to address this.

Looking at the implementation, we currently use one 32- or 64-bit 
counter (depending on the size of "long", I think) for each arc in the 
program. Obviously this memory overhead is a small proportion of the 
text size, but even so, it might be overkill for simple coverage testing 
(as opposed to profiling). However, the code inserted to atomically 
update the counter might end up being quite a large proportion of the 
text, so that's worth looking at too.

If we add a new "counter" that uses one byte per arc, then that's not 
really enough bits for a useful counter, but is more than enough for a 
"visited" flag. Required storage would reduce by a factor of 4 or 8, and 
since nothing ever transitions from "visited" to "unvisited" there will 
be no need for atomic updates, which should reduce the code overhead.

Alternatively, if we use one bit per arc then storage will reduce even 
further, but now we need to do read-modify-write again, so maybe the 
saving is entirely negated.


As for the file format, we can either support the new counter all the 
way through libgcc and gcov, or we can expand it to look like a regular 
counter on stream-out.  This second approach would be a lot less effort, 
and means we retain backwards compatibility with pre-installed gcov 
tools (and even PGO will still be able to locate the most unlikely 
branches?), but the output will be presented as "1" iteration and might 
possibly end up being misleading (at least to the unwary user).

Which approach is likely to be more acceptable to the maintainers?


Thanks in advance

Andrew