Re: [PATCH 01/22] Add condition coverage profiling

[Jan Hubicka <hubicka@ucw.cz>]

> 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