RFC: Reducing Instr PGO size overhead

Thank you for doing this.

The size issue is actually a big concern for me. So this is step in the right direction.

Two other points to consider, that would help us:

  1. When using -fcoverage-mapping, some of the information is emitted in the text section. This is creating linking issues with very large files. It does not seem any of this information should necessarily be in the text section.

  2. Could the information emitted for -fcoverage-mapping be placed into their own section(s)? The objective is to be able to strip the sections for embedded systems. But we could still use the original (unstripped) binary to run llvm-cov.

Thank you

Laurent

Thank you for doing this.

The size issue is actually a big concern for me. So this is step in the
right direction.

Out of curiosity, could you explain your use case a bit more? In particular
could you elaborate on the size issues that you are encountering? (from
past experience, I have a pretty clear idea of google's size issues, so I
didn't explicitly ask for it in this thread).

-- Sean Silva

Hi Sean

I alluded to 2 of the issues in my previous post.

  1. We have a couple of very large libraries. The link fails if I add -fcoverage-mapping. I would think that the mapping information should not matter for the runtime, so I’d expect the link to succeed, even if we have a lot of metadata that will be used by llvm-cov.

  2. We’re shipping the code as an appliance, where the distribution is stored in flash memory. Legacy platforms have a small memory size, so being able to strip the metadata would be very useful. We can keep the object files with the metadata on our data servers, so that they can used when running llvm-cov, but the runtime should be able to use the stripped versions, to save space (and maybe load a bit faster).

Thank you

Laurent

thanks for sharing your use case.

I haven’t able to update on this topic due to other commitments. Will get back to it soon.

David