You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Binaries produced with -fcoverage-mapping enabled tend to have very large coverage mapping sections. For LLVM tools, they are in the hundreds of megabytes range. One factor is that multiple copies of the same source mappings are emitted into binaries (e.g from headers). We should investigate any other contributing factors, and see what can be done to reduce the size of this section.
Note that coverage mapping data is highly compressible. E.g extracting the coverage section from llc and compressing it with gzip gives a 50% size reduction. However, compressing coverage mappings on a per translation unit basis is not a win.
The text was updated successfully, but these errors were encountered:
The compression can be done by a linker plugin. The linker plugin can also have an option to strip the covmap section from the executable and emit it into a separate file.
Another choice is to leave the coverage map data in the object files and only emit minimal mapping data in the executable so that the coverage tool can use to locate the object files (and read covmap data from them)
Extended Description
Binaries produced with -fcoverage-mapping enabled tend to have very large coverage mapping sections. For LLVM tools, they are in the hundreds of megabytes range. One factor is that multiple copies of the same source mappings are emitted into binaries (e.g from headers). We should investigate any other contributing factors, and see what can be done to reduce the size of this section.
Note that coverage mapping data is highly compressible. E.g extracting the coverage section from llc and compressing it with gzip gives a 50% size reduction. However, compressing coverage mappings on a per translation unit basis is not a win.
The text was updated successfully, but these errors were encountered: