IRMutation::mutateModule() currently requires the bitcode size of the module.
To compute the bitcode size, one way is to write the module to a buffer using
BitcodeWriter and calculating the buffer size. This would be fine for a single
mutation, but infeasible for repeated mutations due to the large overhead. It
turns out that the only IR strategy weight calculation method that depends on
the current module size is InstDeleterStrategy, which deletes instructions more
frequently as the module size approaches a given max size. However, there is no
real need for the size to be in bytes of bitcode, so we can use a different
metric. One alternative is to let the size be the number of objects in the
Module, including instructions, basic blocks, globals, and aliases. Although
getting the number of instructions is still O(n), it should have significantly
less overhead than BitcodeWriter. This suggestion would cause a change to the
IRMutator API, since IRMutator::mutateModule() can calculate the Module size
itself.
Details
Details
- Reviewers
Peter - Commits
- rG39b6a7f06ea9: [FuzzMutate] Module size heuristics
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/include/llvm/FuzzMutate/IRMutator.h | ||
---|---|---|
74 | Can you add comments here about the change and the semantics of size? |
Comment Actions
Fix usage of IRMutator::mutateModule in llvm-isel-fuzzer. MaxSize provided is
in bytes of bitcode but we can give it to IRMutator as a reference. writeModule
will silently refuse to save new module if actual bitcode size exceeds MaxSize.
Comment Actions
Fix another usage in llvm-opt-fuzzer. Did a recursive grep and there should be
no other usage left.
Can you add comments here about the change and the semantics of size?