[llvm] [Coverage] Rework Decision/Expansion/Branch (PR #78969)

Alan Phipps via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 31 06:45:38 PST 2024


evodius96 wrote:

> I think this is correct, but the consumer side complexity makes me wonder whether the additional complexity makes our "boring algorithm" overall worse than GCC 

>From the perspective of embedded, I think it makes more sense to keep the instrumentation light and off-load processing in llvm-cov. Also, I think we can look at better modularization of metadata sections (I.e. keeping them in the executable but out of what is loaded in memory, which is what we do downstream and was discussed at the last Developers' meeting embedded workshop). Even going beyond six conditions isn't that bad, but I don't think 32 conditions (as mentioned in GCC context) is at all typical, especially in embedded context. I know we want this to work outside of embedded as well, but we also have to keep in mind when MC/DC is not only useful but practical to fulfill.

Conceivably (just thinking out loud) we may also be able to enable different modes that balance the tradeoffs differently between the different algorithms.



https://github.com/llvm/llvm-project/pull/78969


More information about the llvm-commits mailing list