> On 05/10/2023 22:39, Jørgen Kvalsvik wrote: > > On 05/10/2023 21:59, Jan Hubicka wrote: > > > > > > > > Like Wahlen et al this implementation records coverage in fixed-size > > > > bitsets which gcov knows how to interpret. This is very fast, but > > > > introduces a limit on the number of terms in a single boolean > > > > expression, the number of bits in a gcov_unsigned_type (which is > > > > typedef'd to uint64_t), so for most practical purposes this would be > > > > acceptable. This limitation is in the implementation and not the > > > > algorithm, so support for more conditions can be added by also > > > > introducing arbitrary-sized bitsets. > > > > > > This should not be too hard to do - if conditionalis more complex you > > > simply introduce more than one counter for it, right? > > > How many times this trigers on GCC sources? > > > > It shouldn't be, no. But when dynamic bitsets are on the table it would > > be much better to length-encode in smaller multiples than the 64-bit > > counters. Most expressions are small (<4 terms), so the savings would be > > substantial. I opted for the simpler fixed-size to start with because it > > is much simpler and would not introduce any branching or decisions in > > the instrumentation. > > Oh, and I forgot - I have never seen a real world case that have been more > than 64 conditions, but I suppose it may happen with generated code.
reload.cc has some long hand-written conditionals in it. The first one I counted had 38 conditions. Some of them are macros that may expand to sub-conditions :) But I agree that such code should not be common and probably the conditional should be factored to multiple predicates. Honza
