[MC/DC][Coverage] Loosen the limit of NumConds from 6#82448
[MC/DC][Coverage] Loosen the limit of NumConds from 6#82448
Conversation
This accept current version of profdata. The output might be different. See also https://discourse.llvm.org/t/rfc-coverage-new-algorithm-and-file-format-for-mc-dc/76798
…de)" This reverts commit d168e0c.
Deprecate `TestVectors`, since no one uses it. This affects the output order of ExecVectors. The current impl emits sorted by binary value of ExecVector. This impl emits along the traversal of `buildTestVector()`.
This accepts current version of profdata. The output might be different. See also https://discourse.llvm.org/t/rfc-coverage-new-algorithm-and-file-format-for-mc-dc/76798
* Split out `Indices[ID][Cond]` * Let `Nodes` debug-only. * Introduce `Offset` * Introduce `HardMaxTVs`
* Sink `TVIdxBuilder` into `mcdc::`. * The ctor accepts `SmallVector<ConditionIDs>` indexed by `ID`. * `class NextIDsBuilder` provides `NextIDs` as`SmallVector<ConditionIDs>`, for `TVIdxBuilder` to use it before `MCDCRecordProcessor()`. It was `BranchParamsMap` or `Map` as `DenseMap<Branch>`. * `NodeIDs` and `Fetcher` function are deprecated.
clang/lib/CodeGen/CodeGenPGO.cpp
Outdated
| // bitmap footprint from growing too large without the user's knowledge. In | ||
| // the future, this value could be adjusted with a command-line option. | ||
| unsigned MCDCMaxConditions = (CGM.getCodeGenOpts().MCDCCoverage) ? 6 : 0; | ||
| unsigned MCDCMaxConditions = (CGM.getCodeGenOpts().MCDCCoverage) ? 32767 : 0; |
There was a problem hiding this comment.
I think the limit should be controlled by a flag, with a reasonable default value.
E.g.
-mcdc-max-conditions=<value>
There was a problem hiding this comment.
MaxCond is one of options. I guess it could be configurable just for theirs coding rules, since I think controlling MaxCond would not make sense.
I know we have to introduce other options as well. I will do later.
MaxCondMaxTVsto restrict per-expression number of TVs- "Max bytes of bitmap in the CU" to restict inter-function size of the bitmap.
There was a problem hiding this comment.
I know you will do this later, but I also wanted to echo the desire for a means to control the condition limit to warn the user against unintended memory footprint expansion, most useful in embedded development contexts. It may not otherwise be obvious to most users what is contributing to larger memory usage. We could also override the default in downstream toolchains.
There was a problem hiding this comment.
Also why 32767? Max signed 16-bit value? Is there a reason?
There was a problem hiding this comment.
@evodius96 I've introduced -fmcdc-max-conditions=32767.
against unintended memory footprint expansion
I think-fmcdc-max-test-vectors=64can restrict max bitmap size as the current implementation.
@ornata I have no idea how to determine practical limit for that. So I use SHRT_MAX.
chapuni
left a comment
There was a problem hiding this comment.
Thanks for your comments and sorry for my hasty w-i-p work . I know a few rough implementations would be there.
|
@hanickadot Your comments to They are my preferences. |
Didn't know the context, I saw it green as added. Just ignore it. |
| mcdc::TVIdxBuilder Builder(CondIDs); | ||
| unsigned NumTVs = Builder.NumTestVectors; | ||
| unsigned MaxTVs = CVM.getCodeGenModule().getCodeGenOpts().MCDCMaxTVs; | ||
| assert(MaxTVs < mcdc::TVIdxBuilder::HardMaxTVs); |
There was a problem hiding this comment.
should it be <= or <?
I'm asking because MaxTVs seems like a count, not id
There was a problem hiding this comment.
HardMaxTVs(int_max) is actually the error code.
There was a problem hiding this comment.
Than I would probably make it !=
3rd arg of `tvbitmap.update` was made unused. Remove 3rd arg. Sweep `condbitmap.update`, since it is no longer used.
|
This broke the lit tests on mac: https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/1096/ I'll revert to green for now. |
This broke the lit tests on Mac: https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/1096/ > By storing possible test vectors instead of combinations of conditions, > the restriction is dramatically relaxed. > > This introduces two options to `cc1`: > > * `-fmcdc-max-conditions=32767` > * `-fmcdc-max-test-vectors=2147483646` > > This change makes coverage mapping, profraw, and profdata incompatible > with Clang-18. > > - Bitmap semantics changed. It is incompatible with previous format. > - `BitmapIdx` in `Decision` points to the end of the bitmap. > - Bitmap is packed per function. > - `llvm-cov` can understand `profdata` generated by `llvm-profdata-18`. > > RFC: > https://discourse.llvm.org/t/rfc-coverage-new-algorithm-and-file-format-for-mc-dc/76798 This reverts commit 7ead2d8.
|
Oh, it's apple-specific continuous mode test :( |
By storing possible test vectors instead of combinations of conditions, the restriction is dramatically relaxed. This introduces two options to `cc1`: * `-fmcdc-max-conditions=32767` * `-fmcdc-max-test-vectors=2147483646` This change makes coverage mapping, profraw, and profdata incompatible with Clang-18. - Bitmap semantics changed. It is incompatible with previous format. - `BitmapIdx` in `Decision` points to the end of the bitmap. - Bitmap is packed per function. - `llvm-cov` can understand `profdata` generated by `llvm-profdata-18`. RFC: https://discourse.llvm.org/t/rfc-coverage-new-algorithm-and-file-format-for-mc-dc/76798 -- Change(s) since llvmorg-19-init-14288-g7ead2d8c7e91 - Update compiler-rt/test/profile/ContinuousSyncMode/image-with-mcdc.c
Mostly apparent changes (llvm#82448, llvm#95496) are described here.
By storing possible test vectors instead of combinations of conditions, the restriction is dramatically relaxed. This introduces two options to `cc1`: * `-fmcdc-max-conditions=32767` * `-fmcdc-max-test-vectors=2147483646` This change makes coverage mapping, profraw, and profdata incompatible with Clang-18. - Bitmap semantics changed. It is incompatible with previous format. - `BitmapIdx` in `Decision` points to the end of the bitmap. - Bitmap is packed per function. - `llvm-cov` can understand `profdata` generated by `llvm-profdata-18`. RFC: https://discourse.llvm.org/t/rfc-coverage-new-algorithm-and-file-format-for-mc-dc/76798
[Coverage][MCDC] Adapt mcdc to llvm 19 Related issue: rust-lang#126672 Also finish task 4 at rust-lang#124144 [llvm rust-lang#82448](llvm/llvm-project#82448) has introduced some break changes into mcdc, causing incompatibility between llvm 18 and 19. This draft adapts to that change and gives up supporting for llvm-18.
[Coverage][MCDC] Adapt mcdc to llvm 19 Related issue: rust-lang#126672 Also finish task 4 at rust-lang#124144 [llvm rust-lang#82448](llvm/llvm-project#82448) has introduced some break changes into mcdc, causing incompatibility between llvm 18 and 19. This draft adapts to that change and gives up supporting for llvm-18.
By storing possible test vectors instead of combinations of conditions, the restriction is dramatically relaxed.
This introduces two options to
cc1:-fmcdc-max-conditions=32767-fmcdc-max-test-vectors=2147483646This change makes coverage mapping, profraw, and profdata incompatible with Clang-18.
BitmapIdxinDecisionpoints to the end of the bitmap.llvm-covcan understandprofdatagenerated byllvm-profdata-18.RFC: https://discourse.llvm.org/t/rfc-coverage-new-algorithm-and-file-format-for-mc-dc/76798