[Coverage] ProfileData: Handle MC/DC Bitmap as BitVector. NFC.

[chapuni]

• getFunctionBitmap() stores not std::vector<uint8_t> but BitVector.
• CounterMappingContext holds Bitmap (instead of the ref of bytes)
• Bitmap and BitmapIdx are used instead of evaluateBitmap().

FIXME: InstrProfRecord itself should handle Bitmap as BitVector.

[ornata]

Cool, this looks a lot cleaner.

Are there performance improvements as a result of this change?

The BitVector container provides a dynamic size set of bits for manipulation. It supports individual bit setting/testing, as well as set operations. The set operations take time O(size of bitvector), but operations are performed one word at a time, instead of one bit at a time. This makes the BitVector very fast for set operations compared to other containers. Use the BitVector when you expect the number of set bits to be high (i.e. a dense set).
(https://llvm.org/docs/ProgrammersManual.html#bitvector)

If there are, it would be nice to include them in the commit message.

[chapuni]

@ornata Thanks for the look.

Are there performance improvements as a result of this change?

I haven't measured yet. Since llvm-cov is still so slow with the large data, I think we have to improve it. We could measure then.

If there are, it would be nice to include them in the commit message.

I know I haven't done completely. I guess InstrProfReader could decode ULEB128 into BitVector directly.
It was not my task for now, since it doesn't prevent my improvements.
So, it'd be happy to do when we could improve InstrProfReader.

[chapuni]

Seems this doesn't work on bigendian hosts.
https://lab.llvm.org/buildbot/#/builders/72/builds/2335

[chapuni]

Fixed.
https://lab.llvm.org/buildbot/#/builders/72/builds/2339