We used to emit an S_LOCAL record and zero or more S_DEFRANGE* records
for every local variable. This change makes us emit a single S_BPREL32, S_REGREL32,
or S_REGISTER record for variables that can be described that way. This reduces
the size of the generated debug information.
Details
Diff Detail
- Build Status
Buildable 9714 Build 9714: arc lint + arc unit
Event Timeline
I still need to update/add tests.
This shaves about 11 megabytes off the PDB size for opt:
Before: 307,671,040 bytes
After: 295,956,480 bytes
Unfortunately this seems to have virtually no effect on /DEBUG:FASTLINK PDB size :(. Still good to have anyway since /DEBUG:FULL PDB size is also important, and simpler debug info = better.
I made the change a little more conservative. We now only use the single-record representation
when:
- The variable has only a single defrange.
- There are no gaps in the defrange.
- There S_LOCAL record we would emit would have the default flags.
- The defrange does not have a struct offset.
I also updated all the affected tests to expect the new records.
With that, all tests pass and this change is ready for review.
Size numbers with this version:
Without this change: 320,352,256 opt.pdb
With this change: 310,153,216 opt.pdb
llvm/test/CodeGen/MIR/X86/diexpr-win32.mir | ||
---|---|---|
4 | Can you inject 5 spaces here so that these line up vertically with the CHECK-NEXT statements? | |
33–38 | Why are we still getting some DefRangeRegisterRel even in 32-bit mode with O0? Ranges should be entire blocks or entire functions, which should make them eligible for BPRelativesym | |
llvm/test/DebugInfo/COFF/types-array-advanced.ll | ||
53 | Any idea where this is coming from? It wasn't here before. |
Can you inject 5 spaces here so that these line up vertically with the CHECK-NEXT statements?